UUID-Generator — v4, v7, ULID und NanoID, mit Decoder

Erzeuge UUID v4 oder zeitlich sortierte v7, ULIDs und NanoIDs in großen Mengen, oder füge eine ID ein, um Version und eingebetteten Zeitstempel zu sehen.

Anzahl (1–10.000)

Großbuchstaben Ohne Bindestriche Geschweifte Klammern {…}

Erzeugte UUID v4

ID prüfen und dekodieren

UUID, GUID oder ULID

UUID-Version 7 (nach Unix-Zeit geordnet)

Kanonisch	017f22e2-79b0-7cc3-98c4-dc0c0c07398f
Version	7 – nach Unix-Zeit geordnet
Variante	RFC 9562 / RFC 4122
rand_a (12 bits)	cc3
Zeitstempel	2022-02-22T19:22:22.000Z Unix-ms 1645557742000

IDs werden in deinem Browser mit crypto.getRandomValues erzeugt. Nichts wird gesendet oder gespeichert. Alle kostenlosen Tools ansehen.

Ein Problem gefunden oder etwas, das besser sein könnte? Wir lesen jede Nachricht und beheben Fehler schnell.

Dieser UUID-Generator erzeugt zufällige UUIDs der Version 4, zeitlich sortierte UUIDs der Version 7 nach RFC 9562, ULIDs und NanoIDs – einzeln oder bis zu 10.000 in einem Stapel, den du kopieren oder herunterladen kannst. Jedes Zufallsbit stammt aus crypto.getRandomValues, dem kryptografischen Generator des Browsers, nicht aus Math.random. Der Decoder unten nimmt jede UUID, GUID oder ULID und nennt dir Version und Variante sowie bei v1, v6, v7 und ULID den Zeitpunkt ihrer Erstellung.

Version 7 und ULIDs aus einem Stapel sind streng aufsteigend, auch wenn sich Tausende dieselbe Millisekunde teilen, und sortieren sich daher in Erstellungsreihenfolge, wie es Datenbankschlüssel sollten. Version 1 wird nicht angeboten: Ein Browser hat keinen Zugriff auf eine MAC-Adresse oder eine dauerhafte Clock Sequence, eine in einer Webseite erzeugte v1-UUID würde das Format also nur imitieren. Wenn du v1 oder namensbasierte v3/v5-UUIDs brauchst, erzeuge sie mit der UUID-Bibliothek deiner Programmiersprache.

So funktioniert’s

Wähle den Typ: v4 für eine allgemeine Zufalls-ID, v7 für Primärschlüssel in Datenbanken, ULID oder NanoID, wenn dein Stack sie nutzt.
Lege fest, wie viele du brauchst, bis zu 10.000, und klicke auf „Erzeugen“ (oder drück Enter im Anzahlfeld).
Wähle ein Format: Großbuchstaben, ohne Bindestriche oder in geschweiften Klammern für die Windows-Registry und .NET.
Kopiere alle oder lade sie als Textdatei mit einer ID pro Zeile oder als JSON-Array herunter.
Um eine vorhandene ID zu untersuchen, füge sie in den Decoder ein und sieh dir Version, Variante und einen etwaigen Zeitstempel an.

Häufige Fragen

Was ist der Unterschied zwischen UUID v4 und v7?

Eine v4-UUID besteht aus 122 Zufallsbits ohne Struktur. Eine v7-UUID stellt einen 48-Bit-Unix-Zeitstempel in Millisekunden an den Anfang, gefolgt von 74 Zufallsbits, daher sortieren sich v7-Werte nach Erstellungszeit. Diese Ordnung macht v7 als Primärschlüssel in Datenbanken deutlich freundlicher: Neue Zeilen landen am Ende des Index statt an zufälligen Stellen, was Page Splits reduziert und Inserts schnell hält. Der Preis dafür ist, dass eine v7-ID verrät, wann sie erstellt wurde.

Können zwei UUIDs jemals gleich sein?

Theoretisch ja, praktisch nein, sofern sie aus einer guten Zufallsquelle stammen. Bei 122 Zufallsbits müsstest du etwa 2,7 Trillionen (2,7 × 10^18) v4-UUIDs erzeugen, um eine 50-prozentige Chance auf eine einzige Kollision zu erreichen. Echte Duplikate entstehen durch Bugs: einen schwachen oder schlecht initialisierten Zufallsgenerator, kopierten Zustand virtueller Maschinen oder Code, der einen Wert wiederverwendet.

Ist eine GUID dasselbe wie eine UUID?

Ja. GUID ist Microsofts Name für denselben 128-Bit-Bezeichner, und moderne GUIDs sind Standard-UUIDs (meist Version 4). Die einzigen Unterschiede liegen in der Darstellung: Windows-Tools zeigen GUIDs oft in Großbuchstaben und in geschweiften Klammern, etwa {3F2504E0-4F89-41D3-9A0C-0305E82C3301}. Nutze die Optionen für Großbuchstaben und Klammern, um diese Form zu erhalten.

Sollte ich UUID v7 oder ULID verwenden?

Beide haben 128 Bit, sind zeitlich sortiert und tragen einen Millisekunden-Zeitstempel. UUID v7 passt überall dort, wo es bereits eine UUID-Spalte oder einen UUID-Typ gibt, etwa den uuid-Typ von PostgreSQL oder die UUID-Klasse von Java. ULID ist als Text kürzer (26 statt 36 Zeichen) und unabhängig von Groß-/Kleinschreibung, braucht aber eine eigene Bibliothek und wird als Text oder binär gespeichert. Wenn deine Datenbank und deine Sprache bereits UUID sprechen, ist v7 die einfachere Wahl.

Wie lang sollte eine NanoID sein?

Die standardmäßigen 21 Zeichen aus dem URL-sicheren Alphabet mit 64 Zeichen ergeben 126 Bit Zufall, vergleichbar mit den 122 von UUID v4. Kürzere IDs sind in Ordnung, wenn es wenige IDs gibt und das Erraten einer ID harmlos ist, etwa bei einem Kurzlink mit Rate Limiting. Die Bitzahl unter dem Längenregler zeigt dir, worauf du verzichtest; jedes Zeichen aus einem Alphabet mit 64 Symbolen bringt 6 Bit.

Kann ich sehen, wann eine UUID erstellt wurde?

Nur bei zeitbasierten Versionen. Füge die ID in den Decoder ein: v7 und ULID speichern Unix-Millisekunden in ihren ersten 48 Bits, v1 und v6 speichern 100-Nanosekunden-Intervalle seit dem 15. Oktober 1582. Eine v4-UUID enthält überhaupt keine Zeit, nur Zufallsbits plus die Markierungen für Version und Variante.

Eine UUID lesen: Version und Variante

Eine UUID wird als 32 Hex-Ziffern in Gruppen von 8-4-4-4-12 geschrieben. Zwei Positionen identifizieren sie. Die erste Ziffer der dritten Gruppe ist die Version: In 0190a3c4-1b2c-7d3e-8f40-0123456789ab ist sie 7. Die erste Ziffer der vierten Gruppe kodiert die Variante: 8, 9, a oder b bedeutet das Standardlayout nach RFC 9562, das heute fast jede UUID verwendet.

• v1: Gregorianischer Zeitstempel plus MAC-Adresse des erzeugenden Rechners. Verrät beides; für neue Systeme selten genutzt.

• v3 und v5: deterministisch, abgeleitet aus einem Namespace und einem Namen mit MD5 (v3) oder SHA-1 (v5). Dieselbe Eingabe ergibt immer dieselbe UUID.

• v4: zufällig. Der Standard der meisten Bibliotheken.

• v6: v1 mit umsortiertem Zeitstempel, damit sie sortierbar ist; ein Migrationspfad für v1-Nutzer.

• v7: Unix-Millisekunden-Zeitstempel plus Zufallsbits. Die empfohlene zeitlich sortierte Version für neue Systeme.

• v8: ein herstellerdefiniertes Layout; nur die Bits für Version und Variante sind festgelegt.

Warum zufällige UUIDs Datenbanken bremsen und was v7 behebt

Die meisten Datenbanken speichern einen Primärschlüssel in einem B-Baum-Index. Bei fortlaufenden Schlüsseln landet jede neue Zeile auf der rechtesten Seite des Index, die im Speicher bleibt. Bei zufälligen v4-UUIDs landet jeder Insert auf einer zufälligen Seite; sobald der Index größer als der Arbeitsspeicher ist, müssen Inserts Seiten von der Platte lesen und aufteilen, und der Schreibdurchsatz sinkt. MySQLs InnoDB, das die gesamte Tabelle nach Primärschlüssel clustert, spürt das am stärksten.

UUID v7 behält die Vorteile von UUIDs (global eindeutig, von jedem Client ohne Roundtrip erzeugbar, gefahrlos nach außen sichtbar) und verhält sich im Index fast wie eine Auto-Increment-Spalte. RFC 9562, veröffentlicht im Mai 2024, empfiehlt v7 gegenüber v1 und v6 für neue zeitbasierte IDs, und PostgreSQL 18 hat eine eingebaute Funktion uuidv7() bekommen.

Speichere UUIDs in einem nativen 16-Byte-Typ (uuid in PostgreSQL, BINARY(16) in MySQL) statt als String mit 36 Zeichen, der die Indexgröße mehr als verdoppelt.

UUID vs. ULID vs. NanoID auf einen Blick

• UUID v4: 36 Zeichen, 122 Zufallsbits, universelle Unterstützung in Bibliotheken und Datenbanken, nicht sortierbar.

• UUID v7: 36 Zeichen, 48 Bit Millisekundenzeit plus 74 Zufallsbits, sortierbar, überall unterstützt, wo UUIDs unterstützt werden.

• ULID: 26 Zeichen Crockford-Base32, 48 Bit Zeit plus 80 Zufallsbits, sortierbar und unabhängig von Groß-/Kleinschreibung, braucht eine Bibliothek.

• NanoID: standardmäßig 21 Zeichen, beliebiges Alphabet und beliebige Länge, URL-sicher und kompakt, kein Zeitstempel und keine standardisierte Binärform.