UUID-Generator — v4, v7 und nil

Erzeugen Sie frische UUIDs (v4 oder v7) in Ihrem Browser über die Web-Crypto-API. Wählen Sie die Anzahl, kopieren Sie einen Wert oder alle auf einmal. Nichts wird an einen Server gesendet.

Was ist eine UUID?

Eine UUID (Universally Unique Identifier) ist ein 128-Bit-Wert, formatiert als 32 hexadezimale Zeichen in fünf Gruppen, die durch Bindestriche getrennt sind (8-4-4-4-12). Zwei gut gewählte UUIDs kollidieren extrem unwahrscheinlich, selbst wenn sie auf separaten Maschinen ohne Koordination erzeugt werden — diese Eigenschaft macht sie ideal für Primärschlüssel, Request-IDs, Dateinamen und Idempotenz-Tokens.

UUID v4 ist vollständig zufällig und war jahrelang Standard. UUID v7 (RFC 9562, 2024) bettet einen Millisekunden-Unix-Zeitstempel in die führenden 48 Bits ein, wodurch die IDs nach Erstellungszeit sortierbar und für Datenbank-Indizes deutlich freundlicher werden. Die nil-UUID ist ein All-Null-Platzhalter, um „kein Wert" in Feldern zu kennzeichnen, die eine UUID erfordern.

So verwenden Sie dieses Tool

Wählen Sie eine UUID-Version: v4 für reine Zufälligkeit, v7 für zeitsortierbare IDs, nil für den All-Null-Sentinel.
Wählen Sie, wie viele auf einmal erzeugt werden sollen (1 bis 100). Die Liste regeneriert sofort, sobald Sie eine Einstellung ändern.
Klicken Sie auf Kopieren neben einer Zeile, um einen einzelnen Wert zu greifen, oder auf Alle kopieren, um die ganze Liste (eine UUID pro Zeile) in die Zwischenablage zu legen.

Häufig gestellte Fragen

Sind diese UUIDs kryptografisch sicher?

Ja. Wir verwenden crypto.randomUUID() (oder crypto.getRandomValues() als Fallback) des Browsers, beide stellen den CSPRNG der Plattform bereit. Die zufälligen Bits eignen sich für nicht erratbare Session-Identifier und geheime Tokens.

Sollte ich v4 oder v7 in meiner Datenbank verwenden?

v7 ist meist der bessere Default. Da v7-IDs nach Erstellungszeit sortieren, bleiben B-Tree-Indizes (Standard in PostgreSQL, MySQL, SQL Server) kompakt und Einfügungen treffen die rechte Seite. v4 fragmentiert Indizes und verlangsamt Einfügungen bei großen Tabellen.

Können zwei generierte UUIDs jemals kollidieren?

In der Theorie ja; in der Praxis nicht. v4 hat 122 zufällige Bits — eine Milliarde v4 pro Sekunde über hundert Jahre liefert immer noch eine Kollisionswahrscheinlichkeit unter 1 zu einer Milliarde. v7 mischt 74 zufällige Bits mit einem Zeitstempel, also würden zwei Kollisionen dieselbe Millisekunde und identisches Zufallssuffix erfordern.

Was bedeutet „sortierbar" bei v7?

Sortieren Sie die IDs lexikografisch (String-Sortierung) und Sie erhalten sie nach Erstellungszeit. Diese Eigenschaft entfällt eine separate created_at-Spalte, wenn nur grobe Reihenfolge gebraucht wird, und macht zeit-basierte Abfragen auch ohne Index auf einer Zeitstempel-Spalte effizient.

Ist die nil-UUID sicher zu verwenden?

Sie ist eine gültige UUID und nützlich als Platzhalter, aber niemals für eine echte Entität verwenden — viele ORMs und Frameworks behandeln sie als „nicht vorhanden". Wenn Ihre Datenbank eine NOT NULL UUID-Spalte mit Default hat, bevorzugen Sie DEFAULT gen_random_uuid() (Postgres) oder eine erzeugte v7 statt des nil-Werts.

Häufige Anwendungsfälle

Wo der Griff zu einer UUID die richtige Wahl ist.

Datenbank-Primärschlüssel

Vermeiden Sie sequentielle Integer-IDs, die Geschäftsvolumen in URLs preisgeben und Angreifern Iteration ermöglichen. UUIDs sind nicht erratbar, können clientseitig ohne Datenbank-Roundtrip generiert werden und fusionieren sauber zwischen verteilten Systemen.

Idempotenz-Schlüssel für API-Anfragen

Erzeugen Sie eine UUID pro logischer Benutzeraktion und übergeben Sie sie als Idempotency-Key-Header. Der Server kann Wiederholungen sicher deduplizieren — exakt das Muster, das Stripe und andere Zahlungs-APIs verwenden.

Correlation-IDs in verteilten Logs

Hängen Sie dieselbe UUID an jede Logzeile, Span und Downstream-Anfrage, die eine einzige Benutzeraktion erzeugt. Die Suche nach dieser ID im Aggregator zieht den gesamten Trace über Services hinweg.

Eindeutige Dateinamen

Hochgeladene Dateien als <uuid>.<ext> zu benennen umgeht Namenskonflikte, beseitigt Bedarf an Eingabesäuberung und verhindert Path-Traversal-Angriffe über manipulierte Dateinamen.

Tipps und Kniffe

Gewohnheiten, die das Leben mit UUIDs einfacher machen.

Bevorzugen Sie v7 für neue Schemas

Wenn Sie keinen besonderen Grund haben, völlig unsortierte IDs zu wollen (Sicherheit durch Verschleierung in URLs etwa), ist v7 schneller auf Disk, leichter zu debuggen — Sie können den Zeitstempel lesen — und genauso kollisionsresistent wie v4.

Als nativer UUID-Typ speichern, nicht als String

PostgreSQL, MySQL 8 und SQL Server haben native UUID/UNIQUEIDENTIFIER-Typen, die 16 Bytes statt 36 speichern. Die Platzersparnis zählt im großen Maßstab und der Vergleich ist schneller.

Nicht v1 oder v2 öffentlich exponieren

v1 leakt die MAC-Adresse der erzeugenden Maschine. v2 (DCE Security) leakt POSIX-UID. Beide sind veraltet; verwenden Sie stattdessen v4 oder v7.

Striche entfernen, falls Sie kürzen müssen

Die vier Bindestriche zu entfernen verkürzt den String von 36 auf 32 Zeichen und ist umkehrbar. Vermeiden Sie Base64-Kodierung der Bytes — das Ergebnis ist kürzer (22 Zeichen), aber nicht mehr als UUID erkennbar und bricht Tools, die das kanonische Format erwarten.