UUID-Generator — UUID v4 & v7 Online Generieren
Kryptographisch zufällige UUIDs sofort generieren. Unterstützt v4 (zufällig) und v7 (zeitlich sortierbar, RFC 9562). Einzeln oder bis zu 100 auf einmal generieren. Verwendet crypto.randomUUID() — dein Browser erledigt die Arbeit, nichts erreicht einen Server.
UUID v4 (Random)
Generated using random numbers. No structure, completely random. Suitable for most use cases.
UUID v7 (Time-based)
Generated using a timestamp and random numbers. Sortable by time, improving database performance.
UUIDs (Universally Unique Identifiers) are 128-bit numbers used to identify information in computer systems. The probability of generating two identical UUIDs is virtually zero.
UUID-Versionen Erklärt
Eine UUID ist ein 128-Bit-Bezeichner, formatiert als 32 Hexadezimalziffern in 5 Gruppen: 550e8400-e29b-41d4-a716-446655440000. Die Versionsnummer befindet sich im 13. Zeichen (die „4" in diesem Beispiel bedeutet v4).
UUID v4 ist reiner Zufall — 122 Zufallsbits mit 6 Bits für Versions- und Variantenmarker reserviert. Die Kollisionswahrscheinlichkeit ist astronomisch gering: Man müsste 2,71 × 10^18 UUIDs generieren, um eine 50%ige Chance auf ein Duplikat zu haben. In der Praxis ist das „nie".
UUID v7 (definiert in RFC 9562, veröffentlicht 2024) ist der Neuling. Sie setzt einen Unix-Zeitstempel in die ersten 48 Bits, gefolgt von Zufallsbits. Das bedeutet, dass v7-UUIDs chronologisch sortiert werden — ein großer Gewinn für Datenbankindizes. PostgreSQL und MySQL leiden beide unter zufälligen v4-UUIDs als Primärschlüssel, weil B-Baum-Indizes schlecht fragmentieren, wenn Einfügungen zufällig sind. v7 behebt dies, indem Einfügungen immer an das Ende des Indexes gehen.
Wann was verwenden: v4 für alles, bei dem die Reihenfolge keine Rolle spielt (Sitzungs-Token, Korrelations-IDs, Idempotenz-Schlüssel). v7 für Datenbank-Primärschlüssel, Ereignis-IDs oder alles, was nach Erstellungszeit sortiert wird. Wenn du ein neues Projekt in 2024+ startest, wähle v7 als Standard.
Anleitung
- UUID-Version wählen: v4 (zufällig) oder v7 (zeitlich sortierbar).
- Anzahl festlegen — 1 für schnelles Greifen, bis zu 100 für Massenbedarf.
- Generieren klicken. Ergebnisse erscheinen sofort.
- Einzelne UUIDs oder alle auf einmal kopieren. Kleinbuchstaben mit Bindestrichen, bereit zum Einfügen.
Wann Du Das Brauchst
Datenbank-Primärschlüssel in verteilten Systemen
Auto-Inkrement-IDs funktionieren nicht bei mehreren Schreibknoten. UUIDs lassen jeden Knoten unabhängig IDs erzeugen, ohne Koordination. v7 verwenden wenn chronologische Reihenfolge nötig (meistens), v4 wenn IDs explizit nicht die Erstellungsreihenfolge verraten sollen.
API-Idempotenzschlüssel
Stripe, AWS und die meisten Zahlungs-APIs erfordern einen Idempotenzschlüssel gegen doppelte Gebühren. Pro Anfrage eine v4 UUID generieren — wenn die Anfrage fehlschlägt und mit demselben Schlüssel wiederholt wird, weiß der Server, dass es ein Wiederholungsversuch ist, keine neue Gebühr.
Datei- und Objektbenennung im Cloud-Speicher
Benutzerdateien auf S3 hochladen? UUID als Objektschlüssel verwenden. Keine Kollisionen, kein Bereinigen von Dateinamen nötig, keine Informationslecks über Upload-Reihenfolge (mit v4) oder einfache chronologische Auflistung (mit v7).
Korrelations-IDs für verteiltes Tracing
Am Eingangspunkt einer Anfrage eine UUID generieren und über Header an alle Microservices weiterleiten. Wenn etwas kaputt geht, alle Logs nach dieser UUID durchsuchen, um den vollständigen Anfragepfad zu sehen. v4 ist hier ideal — keine Sortierung nötig, nur Eindeutigkeit.
Wissenswertes
v4 UUIDs sind als Datenbank-Primärschlüssel schlecht (v7 verwenden)
Zufällige v4-UUIDs führen zu B-Baum-Index-Fragmentierung, da Einfügungen an zufälligen Positionen landen. Mehr Seitenteilungen, mehr Festplatten-I/O, langsamere Schreibvorgänge. Benchmarks zeigen 2-3x bessere Insert-Performance mit v7 in PostgreSQL. Wenn du bereits v4 verwendest, ist Migration schwierig — aber für neue Tabellen v7 nehmen.
UUIDs sind keine Geheimnisse
Eine UUID ist ein Identifikator, kein Sicherheits-Token. v7 UUIDs verraten die Erstellungszeit (Zeitstempel in den ersten 48 Bits). v4 UUIDs sind zufällig, haben aber nur 122 Bits Entropie — gut für Eindeutigkeit, nicht für sicherheitsrelevante Token. Für API-Schlüssel oder Sitzungs-Tokens, die Brute-Force widerstehen müssen, 256-Bit-Zufallswerte verwenden.
Als binary(16) in Datenbanken speichern, nicht varchar(36)
Eine UUID als Text besteht aus 36 Zeichen (mit Bindestrichen). Als Binärwert sind es 16 Bytes — weniger als die Hälfte des Speicherplatzes. PostgreSQL hat einen eigenen UUID-Typ (16 Byte). MySQLs BINARY(16) mit UUID_TO_BIN() funktioniert gut. Wichtig bei Millionen von Zeilen mit UUID-Fremdschlüsseln.
Bindestriche nicht entfernen, es sei denn nötig
Das Standardformat ist 8-4-4-4-12 mit Bindestrichen. Manche Systeme entfernen sie (32 Hex-Zeichen). Beide sind gültig, aber Bindestriche machen UUIDs lesbarer und die Versionsziffer (Position 13) leichter erkennbar. Bindestriche beibehalten, es sei denn ein System verlangt ausdrücklich deren Entfernung.
Beispiele
UUID v4 — reiner Zufall
Beachte die „4" an Position 13 (Version) und 8/9/a/b an Position 17 (Variante).
Input
Version: v4Output
f47ac10b-58cc-4372-a567-0e02b2c3d479UUID v7 — zeitlich sortierbar
Beachte die „7" an Position 13. Die ersten 12 Hex-Zeichen codieren den Unix-Zeitstempel in Millisekunden.
Input
Version: v7Output
018f6b2d-3c4a-7b12-9f8e-1a2b3c4d5e6fFunktionen
- UUID v4: 122 Bits kryptographischer Zufall via crypto.randomUUID()
- UUID v7: Millisekunden-Zeitstempel + Zufallsbits (RFC 9562)
- Massengenerierung: bis zu 100 UUIDs mit einem Klick
- Standard 8-4-4-4-12 Format mit Kleinbuchstaben-Hex
- Ein-Klick-Kopie für einzelne oder alle UUIDs
- Läuft 100% im Browser — null Netzwerkanfragen
Häufig Gestellte Fragen
Werden zwei UUIDs jemals kollidieren?
Für v4: Die Wahrscheinlichkeit beträgt 1 zu 2^122 (etwa 5,3 × 10^36). Man müsste 85 Jahre lang 1 Milliarde UUIDs pro Sekunde erzeugen, um eine 50%ige Kollisionswahrscheinlichkeit zu erreichen. In realen Systemen passiert das nicht. Für v7: noch geringeres Risiko, da der Zeitstempel sicherstellt, dass UUIDs aus unterschiedlichen Millisekunden nie kollidieren.
UUID v4 oder v7 für meine Datenbank?
v7, fast immer. Zufällige v4-UUIDs führen zu B-Baum-Index-Fragmentierung — Einfügungen landen an zufälligen Positionen, verursachen Seitenteilungen und verschlechtern die Schreibleistung. v7-UUIDs sind zeitlich geordnet, Einfügungen werden immer am Ende des Indexes angehängt. PostgreSQL-Benchmarks zeigen 2-3x besseren Insert-Durchsatz mit v7. Einziger Grund für v4: wenn du die Erstellungsreihenfolge explizit verbergen musst.
Kann man den Zeitstempel aus einer UUID v7 extrahieren?
Ja. Die ersten 48 Bits einer v7-UUID sind der Unix-Zeitstempel in Millisekunden. Nicht verschlüsselt oder versteckt. Wenn die Erstellungszeit sensible Information ist, v4 verwenden. Für die meisten Anwendungen (Datenbank-IDs, Ereignisprotokolle) ist die Angabe der Erstellungszeit in Ordnung und sogar nützlich.
UUID vs ULID vs nanoid — welche verwenden?
UUID v7 und ULID lösen das gleiche Problem (zeitlich sortierbare eindeutige IDs), aber UUID v7 ist jetzt ein offizieller RFC-Standard (9562). nanoid ist kürzer (21 Zeichen vs 36), aber kein Standard — gut für URL-Slugs, nicht für Datenbank-PKs. Für Interoperabilität und Standardkonformität UUID v7 verwenden. Für kurze IDs in URLs nanoid verwenden.
Wie UUIDs effizient in einer Datenbank speichern?
Den datenbankeigenen UUID-Typ verwenden, falls vorhanden (PostgreSQL hat einen, 16 Byte). In MySQL BINARY(16) mit UUID_TO_BIN(uuid, 1) verwenden — das Swap-Flag ordnet Bytes für bessere Indexleistung mit v1/v7 neu an. Nie als VARCHAR(36) in Tabellen mit hohem Volumen speichern — verschwendet Speicherplatz und verlangsamt Vergleiche. Bei Millionen von Zeilen ist der Unterschied messbar.
Tipps und verwandte Workflows
- Hashen Sie Ihre UUIDs für kürzere Bezeichner mit unserem Hash-Generator.
- Generieren Sie sichere API-Schlüssel zusammen mit UUIDs über unseren Passwort-Generator.
- Formatieren Sie JSON mit UUID-Feldern mit unserem JSON-Formatierer.
- Kodieren Sie UUIDs für URL-Parameter mit unserem URL-Encoder.