UUID v4 Generator

Generate cryptographically random UUID v4

…

Formatieren

Anzahl:

Auch ausprobieren:UUID v1 Generator UUID v7 Generator UUID v3 Generator UUID v2 Generator ULID Generator NanoID Generator CUID Generator CUID2 Generator UUID Decoder

UUID v4 ist die am weitesten verbreitete UUID-Version in moderner Software. Im Gegensatz zu ihren Geschwistern, die Bits aus einem Zeitstempel oder einem Namespace-Hash ableiten, wird UUID v4 vollständig aus Zufallsdaten aufgebaut — was sie zur einfachsten und portabelsten Wahl macht, wenn man einen eindeutigen Bezeichner benötigt, der keine Metadaten über seine Herkunft enthält.

Dieser Generator verwendet crypto.randomUUID(), die native Browser- und Node.js-API, die Entropie aus dem kryptografisch sicheren Zufallszahlengenerator des Betriebssystems bezieht — derselben Quelle, die für TLS-Schlüsselmaterial verwendet wird.

Was ist UUID v4?

Ein Universally Unique Identifier (UUID) ist ein 128-Bit-Label, das in RFC 4122 standardisiert ist. Er wird typischerweise als 32 hexadezimale Ziffern dargestellt, die durch Bindestriche in das Muster 8-4-4-4-12 gruppiert sind:

550e8400-e29b-41d4-a716-446655440000

In UUID v4 sind 122 der 128 Bits zufällig. Die verbleibenden 6 Bits sind Felder, die durch die Spezifikation vorgegeben sind: 4 Bits kodieren die Version (0100 = 4) und 2 Bits kodieren die RFC 4122-Variante (10). Diese festen Bits erklären, warum die dritte Gruppe immer mit 4 beginnt und die vierte Gruppe immer mit 8, 9, a oder b beginnt.

Aufbau einer UUID v4

Aufschlüsselung von 550e8400-e29b-41d4-a716-446655440000:

Segment	Bits	Bedeutung
550e8400	32 zufällig	time_low (Name ist historisch — vollständig zufällig in v4)
e29b	16 zufällig	time_mid (historischer Name — vollständig zufällig in v4)
41d4	4 fest + 12 zufällig	Versions-Nibble `4` (binär `0100`) + 12 zufällige Bits
a716	2 fest + 14 zufällig	Varianten-Bits `10` (MSBs des ersten Bytes) + 14 zufällige Bits
446655440000	48 zufällig	node (vollständig zufällig in v4)

Note:Das Varianten-Nibble am Anfang der vierten Gruppe ist immer eines von 8, 9, a oder b — weil die hohen zwei Bits dieses Bytes auf 10 (den RFC 4122-Variantenmarker) festgelegt sind, was die restlichen zwei Bits frei lässt.

UUID v4 vs. andere Versionen

RFC 4122 definiert fünf UUID-Versionen. Jede löst ein anderes Problem:

UUID v1Zeitstempel + MAC

Kombiniert einen 60-Bit-Zeitstempel (100-Nanosekunden-Intervalle seit Oktober 1582) mit der MAC-Adresse des Hosts. Monoton steigend innerhalb einer Maschine.

Use when: Sie zeitgeordnete IDs benötigen und die Offenlegung der Serveridentität und Generierungszeit akzeptieren.

UUID v3MD5-Hash

Deterministisch: gleicher Namespace + Name ergibt immer dieselbe UUID. Verwendet MD5-Hashing.

Use when: Sie reproduzierbare IDs aus einem bekannten Namespace benötigen (z. B. DNS-Namen). v5 gegenüber v3 bevorzugen.

UUID v4Zufällig

122 Bits kryptografisch sicherer Zufälligkeit. Kein Zeitstempel, keine MAC-Adresse, kein Namespace. Die häufigste Allzweck-Wahl.

Use when: Sie eindeutige IDs ohne strukturelle Bedeutung und maximale Privatsphäre benötigen.

UUID v5SHA-1-Hash

Wie v3, aber mit SHA-1. Immer noch deterministisch aus Namespace + Name.

Use when: Sie reproduzierbare, inhaltsbezogene Bezeichner benötigen (z. B. stabile IDs für Ressourcen, die durch URL identifiziert werden).

UUID v7Zeitgeordnet zufällig

Neuer (RFC 9562, 2024). Kodiert einen Unix-Millisekunden-Zeitstempel in die hohen Bits, dann zufällige Bits. Sortierbar und datenbankfreundlich.

Use when: Sie datenbankindex-freundliche IDs mit natürlicher Zeitreihenfolge benötigen (für neue Projekte gegenüber v1 bevorzugen).

Wann UUID v4 verwenden

UUID v4 ist das richtige Werkzeug in der großen Mehrheit der Situationen, in denen Sie einfach "eine eindeutige ID" ohne zusätzliche Einschränkungen benötigen:

Benutzer- und Konto-IDs

Undurchsichtige Benutzer-IDs, die nichts über den Erstellungszeitpunkt oder die Serveridentität verraten. Können nicht aufgezählt oder erraten werden.

Datenbankprimärschlüssel

Funktioniert mit jeder Datenbank-Engine. UUID v4 kann sicher clientseitig generiert und aus verteilten Quellen zusammengeführt werden, ohne Koordination — keine Sequenztabelle oder zentraler ID-Dienst erforderlich.

Sitzungs- und Token-IDs

122 Bits Zufälligkeit machen Brute-Force-Raten rechnerisch nicht durchführbar — vergleichbar in der Stärke mit einem 122-Bit-Zufalls-Token.

Datei- und Objektnamen

Deduplizierungssichere Dateinamen für Uploads, S3-Objektschlüssel oder Cache-Einträge. Kein Risiko, dass zwei Clients auf denselben Schlüssel schreiben.

Idempotenz-Schlüssel

Generieren Sie eine UUID auf dem Client, bevor Sie eine Anfrage senden. Der Server kann sicher wiederholte Anfragen deduplizieren, ohne einen gemeinsamen Zähler.

Korrelations- und Trace-IDs

Hängen Sie eine UUID an jede Log-Zeile und jeden verteilten Trace-Span an. Keine Koordination zwischen Diensten oder Maschinen erforderlich.

Note:Wenn Ihr Anwendungsfall sortierbare IDs erfordert (z. B. wenn Datenbankzeilen nach Einfügezeit geclustert sein sollen), erwägen Sie stattdessen UUID v7. UUID v4 ist absichtlich zufällig und verursacht bei hohen Einfügeraten Index-Fragmentierung in B-Tree-Indizes.

Kollisionswahrscheinlichkeit

Mit 122 zufälligen Bits enthält der UUID v4-Raum 2¹²² ≈ 5,3 × 10³⁶ mögliche Werte. Die Wahrscheinlichkeit einer Kollision folgt dem Geburtstagsparadoxon:

Generierte UUIDsKollisionswahrscheinlichkeit

1 Milliarde (10⁹)~1 in 5,3 × 10¹⁸

1 Billion (10¹²)~1 in 5,3 × 10¹²

10¹⁸ (1 Exabyte)~1 in 5.300

Die häufig zitierte Kennzahl: Um eine 50%ige Chance auf eine einzelne Kollision zu haben, müssten ungefähr 2,71 × 10¹⁸ UUIDs generiert werden. Mit einer Rate von 1 Milliarde UUIDs pro Sekunde würde das etwa 85 Jahre kontinuierlicher Generierung dauern. Für jede reale Anwendung sind Kollisionen kein praktisches Problem.

Code-Beispiele

JavaScript — Browser und Node.js 14.17+

Die Methode crypto.randomUUID() ist nativ in allen modernen Browsern (Chrome 92+, Firefox 95+, Safari 15.4+) und in Node.js 14.17+ verfügbar. Keine Paketinstallation erforderlich.

// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"

// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())

Node.js — ältere Versionen (uuid-Paket)

const { v4: uuidv4 } = require('uuid')

const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"

Python

python

import uuid

# Generate a UUID v4
id = str(uuid.uuid4())
# → '110e8400-e29b-41d4-a716-446655440000'

# The uuid module uses os.urandom() — cryptographically secure
print(uuid.uuid4().hex)  # without hyphens
# → '110e8400e29b41d4a716446655440000'

Go

import "github.com/google/uuid"

id := uuid.New().String()
// → "110e8400-e29b-41d4-a716-446655440000"

// Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic)
// Always prefer github.com/google/uuid for production use

Rust

toml

# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }

rust

use uuid::Uuid;

let id = Uuid::new_v4().to_string();
// → "110e8400-e29b-41d4-a716-446655440000"

Häufig gestellte Fragen

Ist UUID v4 kryptografisch sicher?

UUID v4 selbst ist kein Sicherheitsprimitiv — es ist ein Bezeichnerformat. Wenn es jedoch über crypto.randomUUID() (Browser oder Node.js) oder entsprechende OS-Level-APIs generiert wird, ist die zugrundeliegende Entropie kryptografisch sicher. Das bedeutet, dass UUID v4-Werte für die Verwendung als Sitzungs-Token oder Idempotenz-Schlüssel geeignet sind, wo Unvorhersehbarkeit wichtig ist. Verwenden Sie keine auf Math.random() basierenden UUID-Generatoren für sicherheitssensible Kontexte — verwenden Sie nur APIs, die explizit aus dem OS-CSPRNG schöpfen.

Können zwei UUID v4 jemals gleich sein?

Theoretisch ja, aber praktisch nein. Die Wahrscheinlichkeit, ein Duplikat in einem realistischen Datensatz (Milliarden von IDs) zu generieren, ist astronomisch gering — weit weniger wahrscheinlich als ein Hardwarefehler, der Datenverfälschung verursacht. UUID v4-Kollisionen werden im Produktionssystem-Design als unmöglich behandelt. Wenn Sie eine Zero-Collision-Garantie wirklich benötigen, verwenden Sie einen zentralisierten Zähler oder eine Datenbanksequenz.

UUID v4 vs nanoid — was soll ich verwenden?

Beide sind durch einen CSPRNG unterstützte Zufalls-ID-Generatoren. Die wesentlichen Unterschiede:

UUID v4 folgt dem RFC 4122-Standard, wird von jeder Datenbank und jedem Framework erkannt und erfordert keine Abhängigkeiten (native crypto.randomUUID()).
nanoid verwendet ein URL-sicheres Alphabet und ist standardmäßig kürzer (21 Zeichen vs. 36). Nützlich, wenn URL-Länge oder Lesbarkeit wichtig ist. Erfordert ein npm-Paket.

Bevorzugen Sie UUID v4, wenn Interoperabilität mit externen Systemen wichtig ist (APIs, Datenbanken, Logging-Infrastruktur). Bevorzugen Sie nanoid, wenn Sie kürzere IDs wollen und den gesamten Stack kontrollieren.

Soll ich UUIDs als Strings oder binär in Datenbanken speichern?

Für die meisten Datenbanken ist die Speicherung als UUID- oder BINARY(16)-Spalte (16 Bytes) effizienter als ein VARCHAR(36)-String (36 Bytes). PostgreSQL hat einen nativen uuid-Typ. MySQL und MariaDB funktionieren gut mit BINARY(16) und den Hilfsfunktionen UUID_TO_BIN() / BIN_TO_UUID(). SQLite-Nutzer speichern typischerweise als TEXT. Die Speicherwahl hat keinen Einfluss auf Eindeutigkeit oder Korrektheit.

Warum hat UUID v4 Bindestriche — und kann ich sie weglassen?

Bindestriche sind Teil der kanonischen UUID-Darstellung, die durch RFC 4122 definiert ist. Sie sind rein kosmetisch — sie tragen keine Information und beeinflussen den 128-Bit-Wert nicht. Das Weglassen ergibt einen kompakten 32-Zeichen-Hex-String, der funktional äquivalent ist. Die meisten UUID-Parser akzeptieren beide Formen. Im Zweifel verwenden Sie die kanonische Bindestriche-Form für maximale Kompatibilität mit Drittanbieter-Tools und Datenbanken.

const id = crypto.randomUUID()              // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '')     // "550e8400e29b41d4a716446655440000"

Sprachleitfäden

UUID v4 in Python erzeugen — uuid.uuid4()