UUID-Generator & Inspektor

UUIDs in jeder gebräuchlichen Version erzeugen – und jede beliebige UUID Bit für Bit aufschlüsseln: welche Version, welche Variante, welcher Zeitpunkt steckt darin, und wie viel davon ist überhaupt Zufall. Alles rechnet dein Browser, nichts verlässt dieses Gerät.

UUIDs erzeugen

Version

Schreibweise

Auf eine erzeugte UUID klicken, um sie unten Bit für Bit aufzuschlüsseln.

UUID aufschlüsseln

Alles läuft lokal in deinem Browser – es wird nichts hochgeladen und nichts gespeichert.

Welche UUID-Version soll ich nehmen?

Die kurze Antwort für fast alle Fälle: Version 7, wenn die IDs in einer Datenbank landen, sonst Version 4. Alles andere sind Sonderfälle mit klarem Anlass.

VersionWoraus sie bestehtWann sie die richtige ist
v4122 Bit ZufallDer Normalfall. Wenn eine ID nur eindeutig sein muss und sonst nichts.
v7Unix-Zeit in ms + Zähler + ZufallPrimärschlüssel in Datenbanken, Event-IDs, alles, was chronologisch sortieren soll.
v5SHA-1 über Namensraum + NameWenn dieselbe Eingabe immer dieselbe ID ergeben muss – etwa eine stabile ID aus einer URL oder Artikelnummer, ohne Zuordnungstabelle.
v3MD5 über Namensraum + NameWie v5, aber mit dem älteren Hash. Nur noch für Kompatibilität mit Bestehendem.
v1Zeitstempel + Clock-Sequence + Node-IDHistorisch verbreitet, unter anderem in älteren Datenbanken. Für Neues gibt es keinen Grund mehr – v7 kann dasselbe besser.
v6wie v1, Zeitfelder umsortiertUmstiegspfad für Systeme, die schon v1 nutzen und Sortierbarkeit brauchen.
v2, v8DCE Security bzw. frei belegbarPraktisch nie. v2 ist ein Relikt aus DCE, v8 ist ausdrücklich für eigene Layouts reserviert – dieses Werkzeug erkennt beide, erzeugt sie aber nicht.

Warum v7 in Datenbanken schneller ist als v4

Der Unterschied hat nichts mit Kryptografie zu tun, sondern mit der Bauform von Indizes. Ein B-Baum, wie ihn PostgreSQL, MySQL und SQL Server für Primärschlüssel verwenden, hält seine Einträge sortiert. Kommt ein neuer Wert hinzu, muss er an die passende Stelle – und die ist bei einer v4-UUID jedes Mal eine andere, zufällig irgendwo im Baum.

Bei vielen Einfügungen bedeutet das: ständig neue Seiten anfassen, die gerade nicht im Arbeitsspeicher liegen, und Seiten, die mittendrin geteilt werden müssen. Der Index wird löchrig und wächst schneller als nötig. Eine v7-UUID beginnt dagegen mit der Zeit. Neue Werte sind fast immer größer als alle bisherigen und landen deshalb am rechten Rand des Baums – auf denselben wenigen Seiten, die ohnehin im Cache stehen. Genau das ist der Grund, warumuuid_generate_v4() in Schreib-Benchmarks so oft schlecht abschneidet und warum MySQL-Nutzer jahrelang eigene „ordered UUID“-Funktionen gebaut haben. Seit RFC 9562 (Mai 2024) ist v7 der offizielle Weg dorthin.

Der Preis: Eine v7-UUID verrät ihren Entstehungszeitpunkt auf die Millisekunde genau. Wo das stört – etwa bei IDs, die öffentlich sichtbar sind und keine Rückschlüsse auf Zeitpunkte erlauben sollen –, bleibt v4 die bessere Wahl.

Wie eine UUID aufgebaut ist

Eine UUID ist ein Wert aus 128 Bit, geschrieben als 32 Hexadezimalziffern in fünf Gruppen:8-4-4-4-12. Sechs dieser Bits sind fest vergeben, und sie stehen bei jeder Version an derselben Stelle: vier Bits für die Version (das erste Zeichen der dritten Gruppe – eine UUID mit einer 7 dort ist eine v7) undzwei Bits für die Variante (die höchsten Bits des ersten Zeichens der vierten Gruppe, weshalb dort in der Praxis fast immer 8, 9, aoder b steht).

Die Variante beantwortet die Frage, nach welcher Regel der Rest überhaupt zu lesen ist. Der Wert 10 steht für RFC 9562 (früher RFC 4122) und damit für alles, was heute üblich ist. 110 markiert die alten Microsoft-GUIDs, 0 das längst vergessene Apollo-NCS-Format. Der Inspektor oben zeigt genau diese sechs Bits kräftig eingefärbt – daran lässt sich auf einen Blick sehen, ob eine Zeichenkette wirklich eine wohlgeformte UUID ist oder nur zufällig danach aussieht.

Die restlichen 122 Bit gehören der jeweiligen Version: bei v4 sind sie vollständig Zufall, bei v7 stecken in den ersten 48 davon die Millisekunden seit 1970, bei v1 und v6 ein Zeitstempel in 100-Nanosekunden-Schritten seit dem 15. Oktober 1582 – dem Tag der gregorianischen Kalenderreform.

Wie eindeutig ist eine UUID wirklich?

Eine v4-UUID hat 122 zufällige Bit, das sind rund 5,3 · 10³⁶ mögliche Werte. Entscheidend ist aber nicht diese Zahl, sondern das Geburtstagsparadoxon: Die Wahrscheinlichkeit, dass sichirgendwo zwei UUIDs gleichen, wächst schneller als die Anzahl der erzeugten Werte vermuten lässt. Die verbreitete Rechnung dazu: Man müsste rund 85 Jahre lang jede Sekunde eine Milliarde UUIDs erzeugen, um mit 50 % Wahrscheinlichkeit auf eine einzige Doppelung zu stoßen.

Diese Sicherheit steht und fällt mit der Qualität des Zufalls. Dieses Werkzeug nutztcrypto.getRandomValues(), den kryptografisch sicheren Zufallsgenerator des Browsers. Wo stattdessen ein schlicht gesetzter Math.random() oder ein mit einem festen Wert initialisierter Generator im Spiel ist, gelten diese Zahlen nicht mehr – Kollisionen in freier Wildbahn gehen fast immer darauf zurück und nicht auf mathematisches Pech.

Namensbasierte UUIDs: v3 und v5

v3 und v5 sind die einzigen Versionen ohne Zufall. Sie hashen einen Namensraum (selbst eine UUID) zusammen mit einem Namen und schneiden die ersten 16 Byte des Digests heraus. Dieselben Eingaben ergeben deshalb überall und jederzeit dieselbe UUID – auf einem anderen Rechner, in einem anderen Jahr, in einer anderen Programmiersprache.

Das ist nützlich, wenn eine ID aus etwas abgeleitet werden soll, das es schon gibt: aus einer Domain, einer URL, einer ISBN. Man braucht dann keine Tabelle, die sich merkt, welche UUID zu welchem Namen gehört – die Zuordnung lässt sich jederzeit neu ausrechnen. RFC 9562 definiert dafür vier Standard-Namensräume (DNS, URL, OID, X.500); für eigene Datenbestände nimmt man eine selbst erzeugte v4-UUID als Namensraum und behält sie bei.

Zwei Fallstricke: Erstens ist eine namensbasierte UUID keine Einbahnstraße im Sicherheitssinne. Wer den Namensraum kennt und den Namen errät, kann die UUID nachrechnen – als Geheimnis taugt sie deshalb nicht. Zweitens ändert sich die UUID, sobald sich der Name ändert, und sei es nur in der Groß-/Kleinschreibung: Gehasht werden die Bytes, nicht die Bedeutung.

Häufige Fragen

Was ist der Unterschied zwischen UUID und GUID?
Keiner, der an der Zahl etwas ändert. GUID („Globally Unique Identifier“) ist Microsofts Name für dasselbe 128-Bit-Konstrukt. Unterschiedlich ist nur die Gewohnheit beim Aufschreiben: In der Microsoft-Welt stehen GUIDs oft in geschweiften Klammern und in Großbuchstaben. Beide Schreibweisen liefert der Generator oben auf Wunsch mit.

Spielt Groß- und Kleinschreibung eine Rolle?
Beim Vergleichen nicht – A1B2 und a1b2 sind dieselbe Zahl. RFC 9562 schreibt vor, dass UUIDs in Kleinbuchstaben ausgegeben und in beiden Schreibweisengelesen werden. Wer UUIDs als Text in einer Datenbank ablegt, sollte sich trotzdem auf eine Form festlegen, sonst findet ein =-Vergleich sie später nicht wieder.

Darf ich eine UUID als Passwort-Ersatz oder Einladungstoken verwenden?
Nur, wenn sie eine v4 aus einem kryptografisch sicheren Generator ist – dann sind 122 Bit Zufall mehr als genug. Bei v1, v6 und v7 ist ein großer Teil der Bits der Zeitstempel und damit vorhersagbar; bei v3 und v5 gibt es gar keinen Zufall. Solche UUIDs sind ratbar und gehören nicht in eine Zurücksetzen-URL.

Verrät eine v1-UUID wirklich die MAC-Adresse?
Die klassische Implementierung schreibt die MAC-Adresse der Netzwerkkarte in die letzten 48 Bit, ja. Genau deshalb ließ sich einst das Melissa-Virus über die GUIDs in Word-Dokumenten seinem Autor zuordnen. Der Inspektor oben zeigt für dieses Feld an, ob das Multicast-Bit gesetzt ist: Ist es das, war die Node-ID zufällig; ist es das nicht, steht dort vermutlich eine echte Netzwerkadresse. Der Generator hier setzt es immer – ein Browser kommt an die MAC ohnehin nicht heran.

Speichere ich UUIDs besser als Text oder als Binärwert?
Als Binärwert, wo die Datenbank es anbietet: 16 Byte statt 36 Zeichen, und der Index bleibt entsprechend kleiner. PostgreSQL hat dafür den eigenen Typ uuid, MySQL nutztBINARY(16). Für Protokolle, Konfigurationsdateien und APIs bleibt die kanonische Textform mit Bindestrichen das Übliche.

Werden die erzeugten UUIDs irgendwo gespeichert?
Nein. Erzeugen und Aufschlüsseln passieren vollständig in deinem Browser; es gibt keinen Server, der etwas entgegennehmen könnte. Gemerkt wird ausschließlich deine Auswahl an Version, Anzahl und Schreibweise – im lokalen Speicher deines Browsers, damit die Einstellungen beim nächsten Besuch noch stimmen.