UUID Generator

Was ist eine UUID?

Eine UUID (Universally Unique Identifier), auch GUID genannt, ist ein 128-Bit-Wert, geschrieben als 32 Hex-Ziffern in fünf durch Bindestriche getrennten Gruppen – 8-4-4-4-12, zum Beispiel f47ac10b-58cc-4372-a567-0e02b2c3d479. Der Sinn dahinter ist ein Identifier, der ohne zentrale Vergabestelle eindeutig ist, sodass voneinander unabhängige Systeme jeweils eigene IDs erzeugen können, die trotzdem nie kollidieren. Die 13. Ziffer kodiert die Version, die 17. die Variante.

UUID-Versionen auf einen Blick

Dieses Tool erzeugt v4, v7, v1 und v5. Die Versionen 2 (DCE Security), 6 (umsortiertes v1) und 8 (custom) braucht man in Anwendungscode so gut wie nie. Das MD5-basierte v3 lassen wir bewusst weg – MD5 gilt als gebrochen und fehlt in der Crypto-API des Browsers – und bieten stattdessen das SHA-1-basierte v5 an, das die Spezifikation bevorzugt.

Welche Version soll ich nehmen?

• Einfach nur eine eindeutige ID? Nehmen Sie v4 (zufällig) – das ist der sichere Standard.
• Primärschlüssel in der Datenbank? Nehmen Sie v7 – der vorangestellte Zeitstempel hält die Inserts in Reihenfolge und vermeidet die Index-Fragmentierung, die zufällige v4-Schlüssel verursachen.
• Soll dieselbe Eingabe immer dieselbe ID ergeben? Nehmen Sie v5 mit Namespace und Name.
• Zusammenspiel mit einem Altsystem? Nehmen Sie v1.

UUID prüfen

Fügen Sie eine beliebige UUID ein, um zu sehen, ob sie gültig ist, und um Version, Variante und (bei v1/v7) den eingebetteten Zeitstempel abzulesen.

Sind UUIDs wirklich eindeutig?

Bei zufälligen v4 ist die Kollisionswahrscheinlichkeit astronomisch klein: Mit 122 Zufallsbits könnten Sie rund 85 Jahre lang eine Milliarde UUIDs pro Sekunde erzeugen und lägen erst dann bei etwa 50 % Wahrscheinlichkeit für ein einziges Duplikat. In der Praxis dürfen Sie sie als eindeutig behandeln. Eine UUID ist allerdings ein Identifier und kein Geheimnis – verwenden Sie sie nie als Passwort oder Security-Token.

Von RFC 4122 zu RFC 9562

UUIDs wurden von der IETF erstmals in RFC 4122 (Juli 2005) standardisiert; dort wurden die Versionen 1 bis 5 definiert und der Namespace urn:uuid: registriert. Fast zwei Jahrzehnte Praxis – vor allem der Siegeszug verteilter Datenbanken – legten eine Lücke offen: Die ursprünglichen zeitbasierten Formate waren nicht dafür gedacht, sich nach Erstellungszeit zu sortieren, und genau das brauchen Datenbanken dringend. RFC 9562, veröffentlicht im Mai 2024, löst RFC 4122 ab und beantwortet diese Nachfrage. Die älteren Versionen bleiben unverändert, drei neue kommen hinzu – v6 (ein umsortiertes v1), v7 (Unix-Millisekunden plus Zufall) und v8 (ein frei belegbares, herstellerdefiniertes Layout) – dazu die neue Max UUID als Sentinel-Wert. Außerdem wurde die alte Microsoft-COM-Variante für außerhalb des Geltungsbereichs erklärt; die modernen Versionen gelten also nur für das gängige Layout „Variante 1“. Kurz gesagt: Nichts von dem, was Sie bereits einsetzen, ist kaputtgegangen, und zeitlich sortierbare IDs sind endlich ein Standard statt eines Flickenteppichs aus inkompatiblen Eigenbauten.

Der Aufbau einer UUID, Bit für Bit

Alle 128 Bit sind vergeben. Über die 16 Oktette hinweg sind zwei kleine Felder reserviert, der Rest trägt die Nutzdaten – je nach Version Zufallsbits, einen Zeitstempel oder einen Hash. Die Version steht in den vier oberen Bits des siebten Oktetts (erste Hex-Ziffer der dritten Gruppe) und liest sich deshalb immer als eine der Ziffern 1–8. Die Variante steht in den oberen Bits des neunten Oktetts (erste Hex-Ziffer der vierten Gruppe); bei jeder Standard-UUID sind diese Bits binär 10 – darum ist diese Ziffer immer 8, 9, a oder b. Zwei reservierte Werte fallen ganz aus dem Versionsschema heraus: die Nil UUID aus lauter Nullen (00000000-0000-0000-0000-000000000000) für „kein Wert“ und die Max UUID aus lauter Einsen (ffffffff-ffff-ffff-ffff-ffffffffffff), die RFC 9562 als Markierung für das Ende eines Bereichs eingeführt hat.

Namensbasierte UUIDs und die vier Standard-Namespaces

Die Versionen 3 und 5 sind deterministisch: Sie hashen eine Namespace-UUID zusammen mit einem Namen als Zeichenkette, dasselbe Paar ergibt also auf jeder Maschine und für immer denselben Identifier. Damit eignen sie sich hervorragend für stabile IDs, die aus vorhandenen Schlüsseln abgeleitet werden – einer URL, einem Dateinamen, einer Domain – ganz ohne Datenbankabfrage und ohne Absprache. Der einzige Unterschied zwischen beiden ist der Hash: v3 nutzt MD5, v5 nutzt SHA-1, und die Spezifikation empfiehlt v5. RFC 4122 definiert vier fertige Namespace-UUIDs, damit unabhängige Systeme bei gleicher Eingabe zum gleichen Ergebnis kommen:

Hasht man etwa den DNS-Namespace mit dem Namen example.com unter v5, kommt in jeder korrekten Implementierung immer dieselbe UUID heraus – genau deshalb sind namensbasierte UUIDs über Servicegrenzen hinweg reproduzierbar, ohne dass irgendein Zustand geteilt werden müsste.

Warum sich Version 7 für Datenbank-Primärschlüssel durchsetzt

Zufällige v4-UUIDs sind schlechte Clustered-Primärschlüssel. Weil jeder Wert unvorhersehbar ist, verteilen sich aufeinanderfolgende Inserts über den gesamten Index; ein B-Baum muss überall in der Struktur Seiten splitten, das Working Set passt nicht mehr sauber in den Cache, und der Schreibdurchsatz sinkt, je größer die Tabelle wird. Eine v7-UUID löst das, indem sie einen 48-Bit-Zeitstempel in Unix-Millisekunden in die höchstwertigen Bits legt, gefolgt von Zufallsbits für die Eindeutigkeit innerhalb derselben Millisekunde. Die Werte wachsen dadurch mit der Zeit und sortieren sich lexikografisch in der Reihenfolge ihrer Erzeugung, neue Zeilen hängen sich also am „rechten Rand“ des Index an – dieselbe Lokalität, die Ihnen ein Auto-Increment-Integer liefert, aber mit der dezentralen, nicht erratbaren und merge-freundlichen Natur einer UUID.

Genau deshalb griffen viele Teams zu ULID, bevor es v7 gab. Eine ULID ist ein 128-Bit-Identifier, der sich zeitlich sortieren lässt – ein 48-Bit-Millisekunden-Zeitstempel plus 80 Zufallsbits – dargestellt als 26 Zeichen in Crockfords Base32 statt in Hex. Sie löst dasselbe Lokalitätsproblem, ist aber kein IETF-Standard, und ihre Textform ist keine gültige UUID. Nachdem RFC 9562 v7 mit im Kern demselben Entwurf standardisiert hat, bekommen neue Projekte zeitlich geordnete IDs und bleiben dabei vollständig UUID-kompatibel – was v7 sowohl gegenüber zufälligen v4-Schlüsseln als auch gegenüber ULID stetig nach vorn bringt.

Die Zahlen hinter „eindeutig“ – und zwei Datenschutz-Fußnoten

Mit konkreten Zahlen lässt sich die Kollisionswahrscheinlichkeit von v4 leichter greifen. Sechs der 128 Bit sind für Version und Variante fest vergeben, es bleiben 122 Zufallsbits – rund 5,3 × 10³⁶ (5,3 Sextillionen) verschiedene Werte. Nach dem Geburtstagsparadoxon bräuchten Sie etwa 2,71 Trillionen UUIDs, bevor eine einzige Kollision wahrscheinlicher wird als keine, und selbst nach 103 Billionen erzeugten UUIDs liegt die Chance auf irgendein Duplikat noch bei ungefähr eins zu einer Milliarde – weit mehr Identifier, als die meisten Organisationen über alle ihre Datenbanken hinweg jemals vergeben werden. Der einzige Vorbehalt: Das gilt nur mit einer guten Zufallsquelle. Ein v4 aus einem schwachen oder falsch initialisierten Pseudozufallsgenerator kann kollidieren – und tut es auch.

Zwei Warnungen sind eine Wiederholung wert. Erstens ist eine UUID ein Identifier, kein Geheimnis – verwenden Sie sie nie als Passwort, API-Key oder Session-Token; dort brauchen Sie einen Wert, der eindeutig und aus einer eigenen kryptografischen Quelle nicht erratbar ist. Zweitens können die zeitbasierten Versionen Informationen preisgeben: Eine klassische v1-UUID enthält sowohl den Erstellungszeitstempel als auch die MAC-Adresse der erzeugenden Maschine – das half Ermittlern seinerzeit dabei, den Autor des Melissa-Virus von 1999 aufzuspüren. Genau deshalb baut dieser Generator v1 mit einem zufälligen Node statt mit einer echten MAC-Adresse, und genau deshalb sind v4 oder v7 die sicherere Wahl, sobald ein Identifier öffentlich sichtbar werden kann. Und schließlich: „GUID“ – der Begriff, den Microsoft verwendet – ist nur ein anderes Wort für UUID; der einzige Haken ist, dass manche alten Microsoft-GUIDs Teile des Werts in einer anderen Byte-Reihenfolge serialisieren. Vergleichen Sie sie deshalb immer als kanonische 8-4-4-4-12-Zeichenkette und nicht als Rohbytes.

UUIDs speichern und formatieren – in der Praxis

Eine UUID ist im Kern 16 Byte groß, geschrieben wird sie aber üblicherweise als 36 Zeichen lange 8-4-4-4-12-Zeichenkette. Wie Sie sie ablegen, macht einen Unterschied. Als rohe 16 Byte gespeichert – der native Typ uuid in PostgreSQL oder BINARY(16) in MySQL – braucht sie weniger als die Hälfte des Platzes einer 36-Zeichen-Textspalte und indiziert schneller; VARCHAR(36) ist bequem, in großem Maßstab aber Verschwendung. Die kanonische Textform ist kleingeschrieben, auch wenn die Spezifikation von Parsern verlangt, Großbuchstaben ebenfalls zu akzeptieren – behandeln Sie Vergleiche also als case-insensitiv und normalisieren Sie Werte beim Einlesen. Die Bindestriche sind reine Gruppierung fürs Auge, manche Systeme lassen sie weg, um vier Zeichen zu sparen – die kanonische, interoperable Form behält sie.

Eine Design-Warnung: Weil v1, v6 und v7 einen Zeitstempel enthalten und v4 nicht erratbar ist, nehmen viele an, jede UUID lasse sich bedenkenlos in einer URL zeigen. Für die Eindeutigkeit stimmt das auch – eine UUID bleibt trotzdem ein Identifier und keine Berechtigung. Hängt die Zugriffskontrolle daran, dass der Wert geheim bleibt („wer den Link hat, darf sehen“), nehmen Sie lieber v4 oder ein eigenes Zufalls-Token statt der zeitbasierten Versionen: Ein durchgesickertes v1 oder v7 verrät ungefähr, wann der Datensatz angelegt wurde – und bei v1 unter Umständen auch, welche Maschine ihn angelegt hat.

Wann eine UUID das falsche Werkzeug ist

UUIDs sind nicht umsonst. Mit 128 Bit sind sie viermal so groß wie ein 32-Bit-Integer und doppelt so groß wie ein 64-Bit-Integer – das summiert sich über Milliarden Zeilen und über jeden Fremdschlüssel, der darauf verweist. Für Menschen sind sie ebenfalls unhandlich: Niemand liest eine Ticketnummer als „f47ac10b-58cc…“ vor. Wenn Ihre IDs innerhalb einer einzigen Datenbank bleiben, die ohnehin eine verlässliche Auto-Increment-Sequenz mitbringt, und Sie keine IDs offline, auf mehreren Knoten oder schon vor dem Insert erzeugen müssen, ist ein schlichter fortlaufender Integer kleiner, schneller und besser lesbar. Zur UUID greifen Sie genau dann, wenn Sie dezentrale Erzeugung brauchen – IDs, die Clients vergeben, die mehrere Server vergeben oder die aus getrennten Systemen ohne Absprache zusammengeführt werden; dort zahlt sich die Garantie „keine zentrale Vergabestelle nötig“ aus. Und wenn Sie das tun, nehmen Sie v7, damit Sie diese Garantie behalten, ohne die Index-Lokalität zu opfern, auf die eine Datenbank angewiesen ist.

Häufige Fragen

Sind UUIDs garantiert eindeutig?

Mathematisch garantiert nicht, praktisch aber schon. Eine UUID v4 enthält 122 Zufallsbits – Sie müssten über Jahre hinweg Milliarden UUIDs pro Sekunde erzeugen, bevor eine Kollision auch nur annähernd wahrscheinlich würde. Version 5 ist bewusst deterministisch: derselbe Namespace und derselbe Name ergeben per Design immer dieselbe UUID.

Welche UUID-Version soll ich nehmen?

Für gewöhnliche eindeutige IDs Version 4 (zufällig). Version 7, wenn sich die IDs nach Erstellungszeit sortieren sollen – ideal als Datenbank-Primärschlüssel, weil sie die Index-Fragmentierung vermeiden, die zufällige v4-Schlüssel verursachen. Version 5, wenn Sie eine reproduzierbare ID aus einem Namen ableiten wollen. Version 1 brauchen Sie im Wesentlichen nur noch für Altsysteme.

Ist eine UUID sicher oder schwer zu erraten?

Eine UUID v4 ist unvorhersehbar genug, dass man sie nicht erraten kann – sie bleibt aber ein Identifier und ist kein Geheimnis. Verwenden Sie sie niemals als Passwort, Session-Token oder Sicherheitsschlüssel; erzeugen Sie dafür ein eigenes kryptografisches Secret.

Was ist der Unterschied zwischen v4 und v7?

Beide sind eindeutig, aber v7 stellt einen Millisekunden-Zeitstempel voran, sodass sich eine Liste von v7-UUIDs in der Reihenfolge ihrer Erzeugung sortiert. v4 ist vollständig zufällig und hat keinerlei Ordnung. Nehmen Sie v7 für Datenbankschlüssel (bessere Index-Lokalität) und v4, wenn die Reihenfolge keine Rolle spielt.

Warum gibt es hier keine Version 3?

Version 3 ist namensbasiert, verwendet aber MD5 – kryptografisch gebrochen, und die Web Crypto API des Browsers stellt MD5 gar nicht bereit. Wir bieten stattdessen Version 5 an, das SHA-1-basierte Gegenstück, das auch die Spezifikation empfiehlt.

Werden die UUIDs kryptografisch sicher und lokal erzeugt?

Ja. Alles entsteht lokal in Ihrem Browser über crypto.randomUUID beziehungsweise crypto.getRandomValues aus der eingebauten Web Crypto API – also über den kryptografisch sicheren Zufallsgenerator des Betriebssystems. Es wird nichts an einen Server gesendet, nichts gespeichert und nichts protokolliert, und nach dem Laden funktioniert die Seite auch offline. Version 1 bekommt einen zufälligen Node, Ihre MAC-Adresse verlässt das Gerät also nie.

Verwandte Tools

• SHA-Hash-Generator
• Unix-Timestamp-Konverter
• Base64-Encoder / -Decoder
• JSON-Formatter & Validator

Alle Entwickler- und Datenkonvertierungen ansehen →