Kostenloser UUID-Generator

Über UUIDs

Eine UUID (Universally Unique Identifier) ist ein 128-bit-Bezeichner, der über Raum und Zeit eindeutig sein soll. Die am weitesten verbreitete Version, UUID v4, wird mit zufälligen oder pseudozufälligen Zahlen erzeugt. Das Format besteht aus 8-4-4-4-12 hexadezimalen Zeichen, zum Beispiel 550e8400-e29b-41d4-a716-446655440000.

Vier Jahrzehnte Geschichte, von Apollo bis RFC 9562

Das UUID-Konzept entstand Mitte der 1980er im Apollo Network Computing System (NCS), entworfen bei Apollo Computer von Paul Leach und Rich Salz, um verteiltes Rechnen ohne zentrale Registrierung zu unterstützen. Das Format wurde 1989 vom Open Software Foundation Distributed Computing Environment (OSF DCE) übernommen und 1995 international als ITU-T X.667 / ISO/IEC 9834-8 standardisiert. Die IETF faltete die Spec im Juli 2005 in RFC 4122 (Leach, Mealling, Salz), der für zwei Jahrzehnte die kanonische Referenz wurde. RFC 4122 wurde von RFC 9562 im Mai 2024 aktualisiert, das alle ursprünglichen Versionen (v1 bis v5) behielt, drei neue Versionen (v6, v7, v8) hinzufügte und die speziellen Konstanten „Nil UUID“ (alles Nullen) und „Max UUID“ (alles Einsen) formal definierte. Die Versionierungs-Linie zählt, weil jede Version andere Eigenschaften tauscht: zeitbasiert (sortierbar, leck-anfällig); namensbasiert (deterministisch aus Eingaben); zufällig (universell, undurchsichtig); Custom (was du brauchst). Die moderne Best Practice für neue Anwendungen hat sich für Primärschlüssel von v4 (zufällig) zu v7 (Timestamp + zufällig) verschoben, während v4 die richtige Antwort für undurchsichtige IDs bleibt, bei denen Sortierbarkeit unerwünscht ist.

Die acht Versionen, in einfacher Sprache

• v1 (Timestamp + MAC-Adresse). 60 Bit Timestamp (100-Nanosekunden-Intervalle seit der gregorianischen Epoche 1582) plus die MAC-Adresse der Ursprungsmaschine. Der Hauptnachteil: sie leakt die MAC-Adresse der erzeugenden Maschine, was ein Datenschutzproblem ist. Der Autor des Melissa-Virus wurde 1999 berühmt-berüchtigt teils dadurch identifiziert, dass v1-UUIDs in Word-Dokumenten zu einer spezifischen Maschine zurückverfolgt wurden.
• v2 (DCE Security). Variante von v1, die eine POSIX-UID/GID enthält. In der Praxis fast nie verwendet; aus Vollständigkeit dokumentiert.
• v3 (namensbasiert, MD5). Deterministische UUID, abgeleitet vom MD5-Hash von (Namespace-UUID + Namensstring). Dieselben Eingaben erzeugen immer dieselbe UUID, nützlich, um natürliche Schlüssel (URLs, Domainnamen, Distinguished Names) in UUID-Form zu übersetzen.
• v4 (zufällig). 122 Bit Zufälligkeit (die verbleibenden 6 Bit sind Versions- + Variant-Tags). Die am weitesten verbreitete Version, der Default, den fast jede „gib mir eine UUID“-Bibliothek zurückgibt.
• v5 (namensbasiert, SHA-1). Wie v3, aber mit SHA-1 statt MD5. Wird für neue Anwendungen v3 vorgezogen, weil SHA-1 weniger kaputt ist als MD5, auch wenn beide bekannte Kollisionsangriffe haben.
• v6 (RFC 9562, Mai 2024, zeitlich geordnet). Ordnet die v1-Timestamp-Bits so um, dass die lexikografische Sortierung der chronologischen entspricht. Löst die Beschwerde „v1 sortiert nicht nach Zeit“; leckt standardmäßig immer noch die MAC-Adresse.
• v7 (RFC 9562, Mai 2024, Unix-Timestamp + zufällig). Die ersten 48 Bit sind der Unix-Timestamp in Millisekunden; die verbleibenden 74 Bit sind zufällig. Sortiert natürlich nach Erstellungszeit, enthält Timestamp-Daten, ohne Maschinenidentität zu leaken, und ist die moderne Empfehlung für Datenbank-Primärschlüssel. Postgres 18+ hat eingebautes uuidv7(); SQL Server hat NEWSEQUENTIALID() mit ähnlichen Eigenschaften.
• v8 (Custom). Reserviert für anwendungs-spezifische Layouts. Das Versionsfeld markiert es als v8 und die Variant-Bits sind korrekt gesetzt; alles andere liegt bei der Anwendung. Verwende es, wenn du deine eigenen strukturierten Daten in den UUID-förmigen Umschlag einbetten musst.

Warum v7 zunehmend gegenüber v4 für Datenbankschlüssel bevorzugt wird

Zufällige Primärschlüssel (v4-UUIDs) haben gut dokumentierte Performance-Kosten in Datenbanken, die Zeilen nach Primärschlüssel in einem B-Tree oder ähnlichem Index organisieren. Jede neue Insertion landet an einer zufälligen Position im Index, was die Indexseiten fragmentiert, die Schreib-Amplifikation auf Disk erhöht und den Page Cache zerstört, weil kürzlich eingefügte Zeilen über viele Seiten verstreut sind, statt zusammengruppiert. Sequenzielle Schlüssel (auto-inkrementierende Integer, ULIDs, v7-UUIDs) fügen alle am rechten Rand des Index ein, was das Working Set klein und die Schreib-Amplifikation minimal hält. Die Kritik am „Random-Key-Anti-Pattern“ geht auf die frühe SQL-Server-Dokumentation zu NEWID versus NEWSEQUENTIALID zurück und wurde von der Postgres-Community für v4 vs v7 erneut artikuliert. Der Trade-off: v7 leckt die Erstellungszeit jeder Zeile, was in manchen Anwendungen ein Datenschutz- oder Informationsleck-Anliegen sein kann (z. B. kannst du sagen, wann ein Account erstellt wurde, indem du seine UUID liest). Für die meisten Anwendungen überwiegt der Performance-Gewinn das Timestamp-Leck; für Anwendungen mit hohem Datenschutzbedarf bleibt v4 die richtige Antwort.

Kollisionswahrscheinlichkeit, die Geburtstagsparadox-Mathematik

UUID v4 hat 122 Bit Zufälligkeit, was etwa 5,3 × 10³⁶ mögliche Werte ergibt. Das Geburtstagsparadox sagt, dass man ungefähr die Quadratwurzel der Namespace-Größe braucht, um eine 50-%-Chance auf irgendeine Kollision zu haben, etwa 2,3 × 10¹⁸ UUIDs. In menschliche Begriffe übersetzt: wenn du kontinuierlich 1 Milliarde UUIDs pro Sekunde erzeugst, brauchtest du etwa 86 Jahre, um eine 50-%-Chance auf eine einzelne Kollision zu haben. Für gewöhnliche Anwendungsraten (tausende oder Millionen pro Tag) ist das praktische Kollisionsrisiko null. Die wahrscheinlichste Ursache von „doppelten UUIDs“ in echten Systemen ist ein fehlerhafter Generator, der Math.random() statt eines CSPRNG verwendet, oder ein Generator mit unzureichender Entropie beim Start, oder ein Prozess, der versehentlich zwei Generatoren identisch seedet, nicht die zugrundeliegende Mathematik. Dieser Generator verwendet crypto.randomUUID() des Browsers (wo verfügbar) oder crypto.getRandomValues(), beide ziehen aus dem CSPRNG des Betriebssystems (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes), derselben Entropie-Quelle, die für TLS-Sitzungsschlüssel verwendet wird.

Browser-Implementierung: crypto.randomUUID()

Die Web Crypto API legt crypto.randomUUID() als Ein-Aufruf-Generator offen, der eine RFC-4122-konforme v4-UUID-Zeichenkette zurückgibt. Sie wurde in Chrome 92 (Juli 2021), Firefox 95 (Dezember 2021) und Safari 15.4 (März 2022) ausgeliefert und ist seit etwa 2022 in allen modernen Browsern Baseline-verfügbar. Für ältere Browser ist der Standard-Fallback, ein 16-Byte-Uint8Array zu allokieren, mit crypto.getRandomValues() zu füllen, das Versions-Nibble auf 4 zu setzen (das hohe Nibble des 7. Bytes = 0x40), die Variant-Bits auf 10xxxxxx zu setzen (die zwei hohen Bits des 9. Bytes = 0x80) und die Bytes als 8-4-4-4-12-Hex-Zeichenkette zu formatieren. Dieser Generator verwendet crypto.randomUUID() wenn vorhanden und sonst den manuellen Fallback, die Ausgabe ist auf jeden Fall identisch, nur leicht langsamer auf dem Fallback-Pfad. Beide Pfade laufen vollständig in deinem Browser; nichts überquert das Netzwerk.

Anwendungsfälle, und was jeder wirklich braucht

• Datenbank-Primärschlüssel: besonders in verteilten oder sharded Systemen, in denen das Koordinieren eines Integer-Counters unpraktisch ist. v7 ist die moderne Empfehlung; v4, wenn du Timestamp-Opazität brauchst.
• API-Request-Korrelations-IDs. Jeder eingehende Request erhält eine UUID, die durch jeden Downstream-Service in der Aufrufkette wandert; Logs jedes Service können über die ID auf den ursprünglichen Request zurückgeführt werden. Stripe, Twilio und AWS X-Ray machen das alle so.
• Idempotenz-Schlüssel für HTTP-Requests. Stripes Idempotency-Key-Header nimmt eine UUID; wenn der Client denselben Request mit demselben Schlüssel wiederholt, gibt Stripe die gecachte Antwort zurück, statt die Karte zweimal zu belasten. Dieses Muster ist jetzt Standard bei Zahlungs-APIs.
• Session-Tokens, mit Vorbehalten. Eine v4-UUID ist kryptografisch zufällig und hat 122 Bit Entropie, was für eine Session-ID mehr als genug ist. Aber Session-Tokens, die nur eine UUID sind, sind anfällig für Enumerationsangriffe, wenn irgendein verwandter Endpoint sie leakt; die moderne Best Practice ist, längere, signierte Tokens (JWTs, Paseto) für Session-State zu verwenden.
• Dateinamen für Upload-Deduplizierung. Erzeuge eine UUID für jeden Upload, speichere die Datei unter /uploads/{uuid}.ext: du wirst nie eine Namenskollision haben, unabhängig vom ursprünglichen Dateinamen, und du kannst nicht versehentlich die Datei eines anderen Nutzers durch Erraten der URL ausliefern.
• Nachrichten-IDs in ereignisgesteuerten Systemen. Kafka, RabbitMQ, AWS SQS und die meisten Pub/Sub-Plattformen empfehlen eine UUID pro Nachricht für Tracing und Deduplizierung; v7 wird zunehmend zum Default wegen der Timestamp-sortierbaren Eigenschaft.
• Generierung von Testdaten. Faker-Bibliotheken in jeder Sprache verwenden UUIDs als Default-IDs für generierte Testzeilen.
• Knoten-Identifikatoren in verteilten Systemen. Ein neuer Knoten, der in einem Cluster hochkommt, erzeugt eine UUID für sich selbst; der Cluster-Koordinator nutzt diese ID, um Traffic zu routen und den Knoten in Logs zu identifizieren.

Alternativen, die zu kennen sich lohnt

UUID ist der universelle Default, aber nicht die einzige Option, und mehrere Alternativen lohnen sich für spezifische Anwendungsfälle zu kennen. ULID (Universally Unique Lexicographically Sortable Identifier, Alex Knol, ~2016): 128 Bit wie UUID, aber als 26 Crockford-Base32-Zeichen statt 32 Hex-Ziffern kodiert, kompakter und case-insensitiv URL-safe. Die ersten 48 Bit sind ein Unix-Millisekunden-Timestamp, sodass ULIDs lexikografisch nach Erstellungszeit sortieren. Konzeptionell sehr nahe an UUID v7, Jahre vor diesem. Snowflake (Twitter, 2010): 64 Bit, viel kleiner als UUID, passt in einen SQL-BIGINT. 41 Bit Timestamp + 10 Bit Maschinen-ID + 12 Bit Sequenz-pro-Millisekunde. Verwendet von Twitter/X, Discord, Instagram und vielen Großsystemen, in denen 64-Bit-Primärschlüssel eine harte Beschränkung sind. KSUID (Segment, 2017): 27 Zeichen, Timestamp mit Sekundenpräzision + 128 Bit Zufall. Tauscht Millisekundenpräzision gegen eine kleinere String-Repräsentation als UUID. nanoid (Andrey Sitnik, 2017): eine winzige Bibliothek, die zufällige URL-safe IDs konfigurierbarer Länge produziert. Der Default von 21 Zeichen liefert ähnliche Kollisionsresistenz wie UUID v4 in viel weniger Bytes. Für eine öffentliche URL, in der du sonst eine UUID einbetten würdest, ist nanoid kürzer und freundlicher. Der Trade-off: nanoid-IDs haben nicht die Versions- + Variant-Markerbits, die sie als UUIDs auszeichnen, also passen sie nicht in Systeme, die UUID-förmige Werte erwarten.

URL-Sicherheit und Formatvariationen

UUIDs in ihrer kanonischen Form mit Bindestrichen (550e8400-e29b-41d4-a716-446655440000) sind URL-safe, jedes Zeichen (Kleinbuchstaben, Ziffern, Bindestriche) ist im von RFC 3986 definierten unreservierten Satz. Das heißt, du kannst eine UUID direkt in einen URL-Path oder Query-String einsetzen, ohne percent-encoden zu müssen. Manche Systeme entfernen die Bindestriche der Kompaktheit halber und produzieren eine 32-Zeichen-Hex-Zeichenkette (550e8400e29b41d4a716446655440000), die immer noch URL-safe ist; die Konvertierung ist umkehrbar, weil die UUID-Struktur fest ist. Einige Systeme wickeln UUIDs in geschweifte Klammern ({550e8400-e29b-41d4-a716-446655440000}), Microsofts GUID-Konvention; die Klammern sind dekorativ und wandern nie in URLs. Manche Systeme schreiben die Hex-Zeichen groß; UUIDs sind laut Spec case-insensitiv, aber Konsistenz innerhalb eines Systems zählt. Dieser Generator bietet alle drei Optionen (Großschreibung, Klammern, ohne Bindestriche) für Kompatibilität mit jeder Pipeline, in die du die UUIDs einspeist.

UUID vs GUID, dasselbe Ding, anderer Name

UUID ist der Standardbegriff, der von IETF, ISO und den meisten Open-Source-Projekten verwendet wird. GUID (Globally Unique Identifier) ist der Microsoft-Begriff, der in Windows, .NET, COM/OLE, SQL Server, Active Directory und der Windows Registry verwendet wird. Beide beziehen sich auf den identischen 128-Bit-Identifier im selben 8-4-4-4-12-Hex-Format. Funktional austauschbar, eine von Windows erzeugte GUID kann überall dort verwendet werden, wo eine UUID erwartet wird, und umgekehrt. Der einzige Unterschied, den man kennen sollte: Microsofts GUID-Erzeugung verwendete historisch UUID v4 in vielen APIs, aber UUID v1 (mit MAC-Adresse) in einigen älteren COM/OLE-Kontexten; das ist in Microsofts COM-Spezifikation dokumentiert. Wenn du eine GUID von einem Microsoft-Ursprungssystem erhältst und wissen willst, welche Version es ist, prüfe das Versions-Nibble (das 13. Hex-Zeichen, '1' für v1, '4' für v4 usw.).

Datenschutz: warum nur-Browser sogar hier zählt

Eine UUID hat keine inhärente Bedeutung, warum spielt es also eine Rolle, dass der Generator lokal läuft? Zwei Gründe. Erstens: Wenn eine UUID als Session-Token, Idempotenzschlüssel oder irgendein anderer geheimnisartiger Identifier verwendet wird, bedeutet das Erzeugen auf einem Drittanbieter-Server, dass dieser Server den Wert vor dir gesehen hat, eine kleine, aber reale Exposition. Zweitens: Serverseitige Generatoren, die „kryptografische Zufälligkeit“ versprechen, können vom Nutzer nicht verifiziert werden; ein fehlerhafter oder bösartiger Server könnte nicht-zufällige Werte zurückgeben, die zufällig aussehen, und du hättest keine Möglichkeit, die Verzerrung zu erkennen. Ein Nur-Browser-Generator führt denselben crypto.randomUUID()-Aufruf aus, den deine Anwendung serverseitig ausführen würde; die Entropie kommt aus derselben Betriebssystem-Quelle (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes); kein Dritter sieht die Ausgabe. Du kannst es überprüfen, indem du den Network-Tab der DevTools öffnest, während du auf Generieren klickst, es gibt keine ausgehenden Anfragen. Nimm die Seite nach dem Laden offline (Flugmodus), und der Generator funktioniert weiter.

Häufig gestellte Fragen

Worin unterscheiden sich UUID und GUID?

Sie sind im Wesentlichen dasselbe. UUID ist der Standardbegriff (RFC 4122), während GUID (Globally Unique Identifier) die Microsoft-Terminologie ist. Beide bezeichnen einen 128-bit-Bezeichner im gleichen hexadezimalen 8-4-4-4-12-Format.

Können zwei UUIDs jemals identisch sein?

Theoretisch ja, doch die Wahrscheinlichkeit ist astronomisch gering. UUID v4 verfügt über 122 zufällige Bits, was etwa 5.3 × 10³⁶ mögliche Werte ergibt. Sie müssten jahrzehntelang Milliarden UUIDs pro Sekunde erzeugen, um eine 50-prozentige Chance auf eine einzige Kollision zu haben.

Sind diese UUIDs kryptografisch sicher?

Ja. Dieser Generator verwendet die Web Crypto API (crypto.getRandomValues), die kryptografisch starke Zufallswerte bereitstellt. Die Ausgabe eignet sich für sicherheitskritische Anwendungsfälle wie Sitzungstoken.

Soll ich UUID v4 oder v7 für meinen Datenbank-Primärschlüssel verwenden?

v7 ist die moderne Empfehlung, wenn deine Datenbank sie unterstützt. v4 (zufällig) fügt an zufälligen Positionen in B-Tree-Indizes ein, fragmentiert den Index und zerstört den Page Cache. v7 (Timestamp + zufällig, RFC 9562 Mai 2024) fügt am rechten Rand des Index ein, weil IDs nach Erstellungszeit sortieren, gleiche Schreibperformance wie auto-inkrementierende Integer, mit der Verteilung und Eindeutigkeit von UUIDs. Postgres 18+ hat eingebautes uuidv7(). Der Trade-off: v7 leckt die Erstellungszeit jeder Zeile, was in manchen Anwendungen ein Datenschutzanliegen sein kann. Für die meisten Anwendungsfälle überwiegt der Performance-Gewinn das Timestamp-Leck.

Was sind ULID, KSUID und nanoid?

Alternative ID-Formate. ULID (Alex Knol, ~2016): 128 Bit wie UUID, aber als 26 Crockford-Base32-Zeichen kodiert; sortiert lexikografisch nach Timestamp. KSUID (Segment, 2017): 27 Zeichen, Timestamp mit Sekundenpräzision + 128 zufällige Bit. nanoid (Andrey Sitnik, 2017): winzige Bibliothek, die URL-safe zufällige IDs konfigurierbarer Länge produziert; der Default von 21 Zeichen ergibt ähnliche Kollisionsresistenz wie UUID v4 in viel weniger Bytes. Snowflake (Twitter, 2010): 64-Bit-IDs, die in einen SQL-BIGINT passen, verwendet von Twitter, Discord und Instagram. Verwende UUID, wenn das empfangende System UUID-Format erwartet; verwende die Alternativen, wenn du spezifische Anforderungen an Größe, Sortierbarkeit oder URL-Freundlichkeit hast.

Werden die UUIDs irgendwohin gesendet?

Nein. Jede UUID wird lokal in deinem Browser über die Web Crypto API erzeugt. Der Generator macht nie eine Netzwerkanfrage, überprüfe es im Network-Tab der DevTools, während du auf Generieren klickst, oder nimm die Seite nach dem Laden offline und bestätige, dass das Werkzeug noch funktioniert. Sicher zum Erzeugen von Session-Tokens, Idempotenz-Schlüsseln oder anderen Identifikatoren, bei denen du nicht willst, dass ein Dritter den Wert vor dir gesehen hat.

Verwandte Werkzeuge