# UUID-Generator URL: https://www.toolflux.app/uuid-generator/ Stand: 2026-05-02 UUID-Generator mit Layout-Diagramm pro Version: v1, v3, v4, v5, v7 und ULID. v7 ist sortierbar, v4 ist Zufall, v3/v5 sind deterministisch. Eine UUID (Universally Unique Identifier) ist ein 128-Bit-Wert. Ihr Zweck: zwei Systeme können IDs unabhängig vergeben und in der Praxis trotzdem nicht kollidieren - kein zentraler Sequenzgeber, keine Koordination nötig. Die einzelnen Versionen mischen Zeitstempel, Zufall und (historisch) Hardware-Bytes unterschiedlich. Welche du nimmst, hängt davon ab, ob die ID sortierbar, deterministisch oder einfach zufällig sein soll. Der Generator unten zeigt das Layout pro Version live: welche Bytes für den Zeitstempel reserviert sind, welche für Zufall, welche für ein Knoten-Feld - und welche Eigenschaften daraus folgen. v7 und v4 nebeneinander: die Sortier-Demo zeigt in zwei Klicks, warum v7 in Datenbanken gewinnt. ## Welche UUID-Version brauchst du wirklich? Drei Fragen reichen meistens: 1. **Brauchst du Sortierbarkeit?** Wenn die ID Primärschlüssel in einer Datenbank wird, oder Event-IDs, oder eine URL-sichere Zeitachse - dann v7 (RFC 9562) oder ULID. Beide beginnen mit einem Zeitstempel auf Millisekunden-Auflösung; eine String-Sortierung folgt der Einfügereihenfolge auf 1 ms genau (innerhalb derselben Millisekunde regelt der Zähler oder Zufall der Implementierung den Rest). 2. **Brauchst du Determinismus?** Wenn dieselbe Eingabe immer dieselbe ID liefern soll - dann v3 (MD5) oder v5 (SHA-1). v5 ist die saubere Wahl. 3. **Sonst:** v4. Reiner Zufall aus den Crypto-APIs des Browsers, kein Zustand, kein Geräte-Leak. v1 brauchst du eigentlich nie - außer ein Legacy-System verlangt es. Die letzten 6 Bytes einer v1-UUID sind ein 48-Bit-Knoten-Feld; je nach Implementierung steht da die MAC-Adresse des erzeugenden Geräts. Die Bibliothek hinter diesem Tool zieht zufällige Knoten-Werte, andere Stacks schreiben die echte MAC. Wer v1-IDs aus Logs oder fremden APIs weiterreicht, behandelt die letzten 6 Bytes besser als potenziell sensitiv. ## Das 128-Bit-Layout pro Version Jede Karte oben zeigt das Layout in farbigen Bändern. Die wichtigen Unterschiede: - **v1 - Zeit + Knoten.** Drei Zeitstempel-Runs (time_low, time_mid, time_hi), permutiert. Ein clock_seq-Feld verhindert Kollisionen bei Uhren-Sprüngen. Die letzten 6 Bytes sind das 48-Bit-Knoten-Feld - historisch die MAC, hier zufällig generiert. - **v3 / v5 - Hash.** Der Output ist der MD5- bzw. SHA-1-Hash von Namensraum + Name. Versions- und Varianten-Bits werden in den Hash hineinkopiert; der Rest sind Hash-Bytes. - **v4 - Zufall.** 122 Bits crypto-Zufall. 4 Bits Version, 2 Bits Variante - das war es. - **v7 - Zeit + Zufall.** 48 Bits ms-Zeitstempel am Anfang, dann 74 Bits für Zufall und/oder einen monotonen Zähler (RFC 9562 lässt die genaue Aufteilung offen). Versions- und Varianten-Bits trennen die zwei Bereiche. - **ULID - Crockford-32.** 48 Bits ms-Zeitstempel + 80 Bits Zufall, dargestellt in 26 Crockford-Base32-Zeichen. Keine 0/O- oder I/L-Verwechslung. | Version | Bits Zufall | Sortierbar | Privacy-relevant | Status | |---|---|---|---|---| | v1 | ~61 (Knoten + Seq, hier zufällig) | halb | Node-Feld potenziell MAC | Legacy | | v3 | 0 (deterministisch) | nein | MD5 alt aber stabil | Legacy | | v4 | 122 | nein | unbedenklich | Aktuell | | v5 | 0 (deterministisch) | nein | unbedenklich | Aktuell | | v7 | 74 (Zufall/Zähler) | ja | Zeit ablesbar | Modern | | ULID | 80 | ja | Zeit ablesbar | Modern | ## v4 oder v7 - die Sortier-Demo unten Die Sortier-Demo unten zieht je 10 v4 und 10 v7 UUIDs in zufälliger Reihenfolge. Klick auf "Alphabetisch sortieren" - die linke Spalte (v4) bleibt durcheinander, die rechte (v7) sortiert sich zurück in die Erzeugungsreihenfolge. Genau das passiert in einer Datenbank, wenn du eine UUID-Spalte als Primärschlüssel und Sortier-Schlüssel benutzt: - Bei v4 schreibt jeder neue Eintrag an eine zufällige Stelle im B-Tree-Index. Die Index-Seiten fragmentieren, das I/O verteilt sich. - Bei v7 sitzen neue Einträge praktisch immer am Ende der sortierten Folge. Die Index-Seiten bleiben dicht, das I/O bleibt sequentiell. In MySQL- und Postgres-Benchmarks der letzten Jahre liegt der Unterschied bei großen Tabellen oft im einstelligen Faktor zugunsten von v7. ULID hat dasselbe Verhalten - nur in einer anderen Notation. ## Wann sind v3 und v5 die richtige Wahl? Wenn die ID aus etwas Stabilem abgeleitet werden soll: einer URL, einem DNS-Namen, einem Pfad, einem Datei-Inhalt. Dieselbe Eingabe → dieselbe ID, ohne dass du selbst eine Datenbank befragen musst. ``` v5(DNS-Namensraum, "example.com") = cfbff0d1-9375-5685-968c-48ce8b15ae17 v5(DNS-Namensraum, "example.com") = cfbff0d1-9375-5685-968c-48ce8b15ae17 ``` Der Namensraum ist eine UUID. RFC 9562 Abschnitt 6.6 (Tabelle 3) definiert vier Standard-Namensräume - DNS, URL, OID, X.500 - die der Generator oben als Presets anbietet. Du kannst auch eine eigene UUID als Namensraum verwenden, etwa eine pro Anwendung, sodass derselbe Name in verschiedenen Anwendungen verschiedene IDs ergibt. v5 ist v3 vorzuziehen, weil SHA-1 als Hash-Funktion robuster ist als MD5 - obwohl in dieser Anwendung keine kryptografische Sicherheit gefragt ist; es geht nur um eine gute Verteilung der Bits. ## Was ist mit v6, v8 und Microsoft-GUIDs? - **v6** ist v1 mit umgeordneten Zeitstempel-Bytes - sortierbar wie v7. Das Knoten-Feld trägt dieselbe MAC-Frage wie v1: je nach Implementierung kann es die echte Adresse enthalten oder ein zufälliger Wert sein. Kaum Verbreitung; in der Praxis gewinnt v7. - **v8** ist die "Custom"-Version aus RFC 9562 für proprietäre Layouts. Wenn du sie brauchst, weißt du es; wenn nicht, brauchst du sie nicht. - **Microsoft-GUIDs** sind UUIDs in einer Big-Endian/Little-Endian-Mischform. Beim Austausch zwischen .NET-Welt und allem anderen darauf achten, dass die ersten drei Felder evtl. byte-getauscht sind. ## Bulk-Generierung: 1, 10, 100, 1000 Der Schalter "Wie viele?" oben zieht die gewählte Anzahl in einem Rutsch. Die Liste lässt sich dann als JavaScript-Array, CSV oder JSON kopieren - praktisch für Seed-Daten, Lasttests oder einfach um zu sehen, wie sich das Layout über viele Einträge verhält. Bei v7 rückt der ms-Zeitstempel vorne pro Eintrag um eine Millisekunde vor (damit die Demo eine deutliche Sortier-Spur hat); bei v4 sieht man die Gleichverteilung des Zufalls. ## Häufige Fragen ### Welche UUID-Version soll ich nehmen? Standard ist v4 für Session-IDs und alles ohne Sortier-Bedarf. v7 für Datenbank-Primärschlüssel und Event-IDs - der Zeitstempel am Anfang macht v7 sortierbar. v3 und v5 nur, wenn du deterministische IDs aus Namen brauchst (v5 ist v3 vorzuziehen). v1 nur in Legacy-Systemen - das Knoten-Feld kann je nach Stack die MAC enthalten. ### Was ist UUID v7 und warum ist sie sortierbar? v7 (RFC 9562, 2024) beginnt mit 48 Bits ms-Zeitstempel, gefolgt von 74 Bits für Zufallsdaten und/oder einen monotonen Zähler (zwischen Versions- und Varianten-Bits aufgeteilt). Weil der Zeitstempel die ersten Bytes belegt, sortieren sich v7-UUIDs lexikographisch nach Millisekunden-Zeit; innerhalb derselben Millisekunde regelt der Zähler oder Zufall der Implementierung den Rest. In Datenbanken bedeutet das deutlich weniger Index-Fragmentierung als bei v4. ### Leakt eine v1-UUID meine MAC-Adresse? Kann sein. Die letzten 6 Bytes sind ein 48-Bit-Knoten-Feld - historisch die MAC, je nach Implementierung aber auch zufällig. Wenn du v1-IDs aus unbekannten Stacks weiterreichst, nimm lieber v4 oder v7. ### Was ist der Unterschied zwischen UUID und ULID? ULID ist kein RFC, sondern ein populäres Schema: 26 Zeichen Crockford-Base32, 48 Bits ms-Zeitstempel + 80 Bits Zufall. Lexikographisch sortierbar wie v7, URL-freundlicher und ohne Verwechslung von 0/O oder I/L. ### FAQ **Welche UUID-Version soll ich nehmen?** Standard ist v4 (Zufall) für Session-IDs und alles ohne Sortier-Bedarf, oder v7 (RFC 9562) für Datenbank-Primärschlüssel und Event-IDs - der Zeitstempel am Anfang macht v7 als String und als binärer Schlüssel sortierbar. v3 und v5 nur, wenn du deterministische IDs aus Namen brauchst. v1 nur in Legacy-Systemen - das 48-Bit-Knoten-Feld kann je nach Implementierung die MAC des erzeugenden Geräts enthalten. **Was ist UUID v7 und warum ist sie sortierbar?** v7 ist in RFC 9562 (2024) standardisiert. Layout: 48 Bits ms-Zeitstempel am Anfang, dann 74 Bits für Zufallsdaten und/oder einen monotonen Zähler (RFC 9562 lässt die Aufteilung offen), plus Versions- und Varianten-Bits dazwischen. Weil der Zeitstempel die ersten Bytes belegt, sortieren sich v7-UUIDs nach dem Millisekunden-Präfix; innerhalb derselben Millisekunde hängt die Reihenfolge davon ab, ob die Implementierung einen monotonen Zähler oder Zufall in den restlichen Bits führt. In Datenbanken bedeutet das deutlich weniger Index-Fragmentierung als bei v4. **Leakt eine v1-UUID meine MAC-Adresse?** Kann sein. v1 reserviert die letzten 6 Bytes für ein 48-Bit-Knoten-Feld - historisch die MAC-Adresse des erzeugenden Geräts. RFC 9562 erlaubt aber auch zufällige Knoten-Werte, und die Bibliothek hinter diesem Generator (das uuid-Paket) zieht zufällig. Andere v1-Implementierungen schreiben die echte MAC. Wenn du v1-UUIDs aus fremden Stacks weiterreichst, behandle die letzten 6 Bytes als potenziell sensitiv. **Was ist der Unterschied zwischen UUID und ULID?** ULID ist kein RFC, sondern ein populäres Schema von Alizain Feerasta: 26 Zeichen Crockford-Base32 (statt 36 Zeichen UUID-Notation), 48 Bits ms-Zeitstempel + 80 Bits Zufall. Lexikographisch sortierbar wie v7, aber URL-freundlicher und ohne Verwechslung von 0/O oder I/L. Wenn du den UUID-Standard nicht zwingend brauchst und kürzere IDs willst, ist ULID die pragmatische Wahl. **Wie deterministisch sind v3 und v5?** Vollständig: dieselbe Eingabe (Namensraum + Name) liefert immer dieselbe UUID. v3 nutzt MD5, v5 nutzt SHA-1 - beide sind nicht reversibel zum Namen, aber beide sind keine kryptografischen Geheimnisse. Für stabile IDs aus URLs, Pfaden oder Slugs ist v5 die bessere Wahl wegen SHA-1 statt MD5. **Wie generiere ich 1000 UUIDs auf einmal?** Im Generator oben den Schalter 'Wie viele?' auf 1000 stellen. Die Liste lässt sich dann als JavaScript-Array, CSV oder JSON kopieren. Bei v4 zieht jede UUID einen frischen 122-Bit-Zufall aus den Crypto-APIs des Browsers; bei v7 bleibt die Reihenfolge erhalten und der Zeitstempel rückt pro Eintrag um eine Millisekunde vor. Diese ULID-Implementierung ist innerhalb derselben Millisekunde monoton (der Zufalls-Tail wird inkrementiert); der ULID-Standard verlangt das nur für explizit monotone Generatoren. **Welche UUID-Version sortiert sich nach Erzeugungszeit?** v7 und ULID. v1 ist halb-sortierbar - der Zeitstempel ist da, aber RFC 4122 permutiert die Bytes (time_low / time_mid / time_hi), sodass eine String- oder binäre Sortierung nicht der Erzeugungszeit folgt. v4, v3, v5 sind nicht sortierbar; v3/v5 sind sogar deterministisch, also komplett unabhängig vom Zeitpunkt der Erzeugung.