Die UUID-Tools von ToolDeck decken alle wichtigen eindeutigen Bezeichnerformate an einem Ort ab. Die Sammlung umfasst: UUID v4 Generator für zufällige, kryptografisch sichere IDs; UUID v7 Generator für zeitstempel-sortierbare Primärschlüssel; UUID v1 Generator für Zeit-und-MAC-basierte Bezeichner; UUID v2 Generator für ältere DCE-Systeme; UUID v3 Generator für deterministische MD5-basierte IDs; ULID Generator für kompakte sortierbare Strings; NanoID Generator für kurze URL-sichere Token; CUID Generator für das ursprüngliche kollisionsresistente Format; CUID2 Generator für seinen modernen Nachfolger; und UUID Decoder zum Inspizieren bestehender Bezeichner. Alle Tools laufen vollständig im Browser über die Web Crypto API — keine Daten werden an Server übertragen, kein Konto erforderlich.
Was sind UUID- und eindeutige ID-Tools?
Eine UUID (Universally Unique Identifier) ist ein 128-Bit-Bezeichner, der in RFC 9562 (früher RFC 4122) standardisiert ist. Als 32 hexadezimale Zeichen im Format 8-4-4-4-12 geschrieben, sieht eine UUID so aus: 550e8400-e29b-41d4-a716-446655440000. Der Standard definiert mehrere Versionen, die jeweils eine andere Strategie zur Garantie der Eindeutigkeit verwenden: Zufallszahlen, Zeitstempel oder deterministisches Hashing.
UUIDs wurden entwickelt, damit verteilte Systeme Bezeichner ohne zentrale Koordination generieren können. Ob du einen Primärschlüssel in PostgreSQL vergibst, einen Session-Token in einer Webanwendung generierst oder eine Datei im Objektspeicher benennst — UUIDs ermöglichen es jedem Knoten im System, unabhängig eine global eindeutige ID zu erstellen, mit einer Kollisionswahrscheinlichkeit, die in der Praxis vernachlässigbar ist.
Über den UUID-Standard hinaus sind verschiedene alternative eindeutige ID-Formate entstanden, um spezifische Einschränkungen zu beheben: ULID und UUID v7 fügen lexikografische Sortierbarkeit für effiziente Datenbankindizes hinzu; NanoID reduziert die Größe für URLs und Cookies; CUID2 priorisiert fingerprint-basierte Kollisionsresistenz für die clientseitige Generierung bei hohem Volumen.
Warum UUID-Tools auf ToolDeck verwenden?
Die UUID-Tools von ToolDeck laufen vollständig im Browser. Keine API-Aufrufe, keine serverseitige Verarbeitung, keine protokollierten Daten. Jeder Generator verwendet die Web Crypto API (crypto.getRandomValues) für kryptografisch starke Entropie — dieselbe Quelle, die Browser für TLS-Schlüsselmaterial verwenden.
🔐Kryptografisch starke Entropie
Alle zufallsbasierten Generatoren (UUID v4, NanoID, CUID2) verwenden crypto.getRandomValues, nicht Math.random. Die Ausgabe ist für sicherheitssensible Anwendungsfälle wie Session-Token und API-Schlüssel geeignet.
📦Alle wichtigen ID-Formate an einem Ort
UUID v1 bis v7, ULID, NanoID, CUID und CUID2 — alle Formate, die ein Entwickler benötigt, mit Optionen zur Massengenerierung und zum Kopieren mit einem Klick.
🔍Bestehende IDs dekodieren und inspizieren
Der UUID Decoder extrahiert Version, Variante, Zeitstempel und Knotenfelder aus jeder UUID. Nützlich zum Debuggen, Auditieren und Verstehen von Legacy-IDs in der Codebasis.
⚡Kein Setup, funktioniert offline
Keine Installation, keine Registrierung, keine Laufzeitabhängigkeiten. Seite öffnen und generieren. Alle Tools funktionieren offline, sobald die Seite geladen ist — nützlich in air-gapped Umgebungen oder eingeschränkten Netzwerken.
Anwendungsfälle der UUID-Tools
Eindeutige Bezeichner kommen auf jeder Ebene des Stacks vor. So nutzen verschiedene Rollen UUID-Generierungstools:
Datenbankprimärschlüssel
Backend-Ingenieure vergeben UUID v4 oder UUID v7 als Primärschlüssel in PostgreSQL, MySQL und MongoDB. Das Zeitstempel-Präfix von UUID v7 hält die Zeilen physisch geordnet auf der Festplatte und vermeidet Seitenteilungen bei schreibintensiven Workloads.
Frontend-Zustand und Komponenten-IDs
Frontend-Entwickler verwenden NanoID oder UUID v4, um stabile React-Keys für dynamisch erstellte Listenelemente, Dialog-IDs für ARIA-Barrierefreiheitsattribute und Idempotenz-Token für Formularübermittlungen zu generieren.
Verteilte Event-Streams
In event-getriebenen Systemen benötigt jedes Event eine global eindeutige, sortierbare ID. DevOps- und Plattformingenieure verwenden ULID oder UUID v7, damit Kafka-Consumer, Log-Aggregatoren und Audit-Trails nach Erstellungszeit sortiert werden können, ohne ein sekundäres Zeitstempelfeld zu benötigen.
Testdatengenerierung
QA-Ingenieure generieren UUID-Batches in Masse, um Testdatenbanken mit realistischen, nicht-sequentiellen IDs zu befüllen. Deterministisches UUID v3 oder v5 ermöglicht die Regenerierung derselben ID aus einer bekannten Eingabe — nützlich für reproduzierbare Test-Fixtures.
Microservice-Korrelations-IDs
Das Anhängen einer UUID an jede eingehende HTTP-Anfrage und deren Weitergabe über Service-Aufrufe (X-Request-ID-Header) ermöglicht verteilten Tracing-Systemen, Logs über Services hinweg zu korrelieren. UUID v4 ist der De-facto-Standard für Request-Korrelation.
Asset- und Ressourcenbenennung
Schlüssel im Objektspeicher (S3, GCS, Cloudflare R2) und CDN-Asset-Dateinamen betten oft eine UUID ein, um Cache-Kollisionen und URL-Erraten zu verhindern. Das kompakte 21-Zeichen-Format von NanoID reduziert die URL-Länge gegenüber vollständigen 36-Zeichen-UUIDs.
UUID-Versions- und Formatreferenz
Die folgende Tabelle vergleicht alle UUID-Versionen mit den am häufigsten verwendeten UUID-Alternativen. Damit lässt sich schnell ermitteln, welches Format die eigenen Anforderungen erfüllt.
| Bezeichner | Algorithmus | Sortierbar | Deterministisch | Ideal für |
|---|
| UUID v4 | Zufällig (CSPRNG) | — | — | Allgemeine IDs, Session-Token, Primärschlüssel |
| UUID v7 | Unix-ms-Zeitstempel + zufällig | ✓ | — | Sortierbare Primärschlüssel, verteilte Event-IDs (RFC 9562) |
| UUID v1 | Zeitstempel + MAC-Adresse | ✓ | — | Zeitgeordnete IDs, Einzelknoten-Systeme, Legacy-Kompatibilität |
| UUID v3 | Namespace + Name + MD5 | — | ✓ | Reproduzierbare IDs aus bekannten Eingaben (DNS, URLs) |
| UUID v5 | Namespace + Name + SHA-1 | — | ✓ | Wie v3 mit stärkerem Hash; v5 gegenüber v3 bevorzugen |
| UUID v2 | Zeitstempel + DCE UID/GID | ✓ | — | Legacy-POSIX/DCE-Umgebungen; für neue Projekte vermeiden |
| ULID | Zeitstempel-Präfix + zufällig | ✓ | — | Sortierbare IDs, URL-sicher, ohne Bindestriche (26 Zeichen) |
| NanoID | Zufällig (CSPRNG), URL-sicheres Alphabet | — | — | Kurze IDs für URLs, Cookies, HTML-Attribute (21 Zeichen) |
| CUID2 | Fingerprint + Zeitstempel + zufällig | — | — | Clientseitige Generierung mit hohem Volumen, kollisionsresistent |
UUID v3 und v5 sind deterministisch: derselbe Namespace + Name erzeugt immer dieselbe UUID. Alle anderen Formate generieren bei jedem Aufruf einen neuen Wert.
Das richtige UUID-Tool auswählen
Der richtige Bezeichner hängt von den Anforderungen an Sortierbarkeit, Größe und Determinismus ab. Diese Entscheidungshilfe hilft weiter:
- 1
Wenn du eine allgemeine eindeutige ID ohne besondere Anforderungen benötigst → UUID v4 Generator - 2
Wenn du IDs benötigst, die chronologisch sortiert werden und mit dem UUID-Standard kompatibel sind → UUID v7 Generator - 3
Wenn du zeitgeordnete IDs mit eingebettetem Zeitstempel für Einzelknoten- oder Systeme mit geringer Parallelität benötigst → UUID v1 Generator - 4
Wenn du sortierbare IDs benötigst, die URL-sicher und ohne Bindestriche sind → ULID Generator - 5
Wenn du kompakte, URL-sichere IDs benötigst, die kürzer als eine vollständige UUID sind → NanoID Generator - 6
Wenn du viele IDs clientseitig generierst und starke Kollisionsresistenz benötigst → CUID2 Generator - 7
Wenn du das CUID v1-Format für Kompatibilität mit bestehenden Systemen auf Basis der ursprünglichen Spezifikation benötigst → CUID Generator - 8
Wenn du dieselbe ID deterministisch aus einem Namespace und einem Namen reproduzieren musst → UUID v3 Generator - 9
Wenn du mit Legacy-DCE- oder POSIX-Systemen arbeitest, die v2-Bezeichner erfordern → UUID v2 Generator - 10
Wenn du eine bestehende UUID hast und ihre Version, Variante oder ihren Zeitstempel inspizieren möchtest → UUID Decoder
Sowohl UUID v7 als auch ULID bieten Zeitstempel-Präfixe mit Millisekundengenauigkeit und lexikografische Sortierbarkeit. Der wesentliche Unterschied: UUID v7 verwendet das Standard-UUID-Format (8-4-4-4-12, 36 Zeichen) für maximale Ökosystem-Kompatibilität, während ULID eine eigene Base32-Kodierung verwendet (26 Zeichen, URL-sicher, ohne Bindestriche). Wenn die Datenbank, das ORM oder das Framework nativ UUID-Spalten unterstützt, ist UUID v7 vorzuziehen. Werden kürzere IDs ohne Framework-Einschränkungen benötigt, ist ULID kompakter.
Häufig gestellte Fragen
Was ist eine UUID?
Eine UUID (Universally Unique Identifier) ist ein 128-Bit-Wert, der in RFC 9562 standardisiert ist. Sie wird als 32 hexadezimale Ziffern in fünf durch Bindestriche getrennten Gruppen geschrieben: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Der Standard definiert mehrere Versionen mit unterschiedlichen Eindeutigkeitsstrategien — zufällig (v4), zeitstempelbasiert (v1, v7) oder deterministisch namensbasiert (v3, v5).
Was ist der Unterschied zwischen UUID v4 und UUID v7?
UUID v4 füllt alle 122 nicht-fixen Bits mit Zufallsdaten aus einer kryptografisch sicheren Quelle. UUID v7 kodiert einen 48-Bit-Unix-Millisekundenzeitstempel in den ersten 48 Bits, gefolgt von Zufallsbits. Das Ergebnis: UUID v7 sortiert chronologisch als einfacher String, was Datenbankindex-B-Trees bei Einfügungen geordnet hält. UUID v7 wurde in RFC 9562 (April 2024) hinzugefügt und ist die bevorzugte Wahl für neue Datenbankprimärschlüssel.
Sind UUID v4-Werte kryptografisch sicher?
UUID v4-Werte werden mit einem kryptografisch sicheren Pseudozufallszahlengenerator (CSPRNG) generiert. Sie sind als nicht-erratbare Token geeignet — Session-IDs, Passwort-Reset-Links und ähnliches. Eine UUID ist jedoch kein Geheimnis für sich: Sie hat kein HMAC, kein Ablaufdatum und keine Bindung an einen bestimmten Benutzer. UUIDs sollten als opake Bezeichner behandelt werden, nicht als Authentifizierungsdaten.
Können zwei verschiedene Systeme dieselbe UUID generieren?
Die Kollisionswahrscheinlichkeit für UUID v4 beträgt etwa 1 zu 2^122 pro Paar. Um eine 50-%-Chance auf irgendeine Kollision zu haben, müssten etwa 2,7 × 10^18 UUIDs generiert werden — weit über dem, was ein reales System erzeugt. UUID v1 und v7 betten zusätzlich einen Zeitstempel und/oder Zufallsbits ein, was versehentliche Kollisionen noch unwahrscheinlicher macht. Für alle praktischen Zwecke werden UUIDs von separaten Systemen nicht kollidieren.
Warum sind UUIDs 36 Zeichen lang?
Eine UUID besteht aus 128 Bit = 16 Byte. In Hexadezimal kodiert ergibt das 32 Zeichen. Das UUID-Format fügt 4 Bindestriche an festen Positionen ein (nach Gruppen von 8, 4, 4 und 4 Hex-Ziffern), um die Lesbarkeit zu verbessern und Version sowie Variantenbits leicht erkennbar zu machen, was insgesamt 36 Zeichen ergibt. Die Bindestriche tragen keine Daten.
Was ist ULID und wie unterscheidet es sich von UUID?
ULID (Universally Unique Lexicographically Sortable Identifier) ist ein 128-Bit-Bezeichner, der in Crockford Base32 kodiert ist (26 Zeichen, groß-/kleinschreibungsunabhängig, ohne Bindestriche). Die ersten 48 Bits kodieren die Unix-Zeit in Millisekunden; die restlichen 80 Bits sind zufällig. ULIDs sortieren als einfache Strings korrekt und sind kompakter als UUIDs. Sie sind nicht Teil des UUID-RFCs — sie verwenden eine andere Kodierung und fehlen die Versions-/Variantenfelder von UUIDs.
Sollte ich UUIDs oder Auto-Inkrement-Integer als Primärschlüssel verwenden?
Auto-Inkrement-Integer sind sequentiell, kompakt und indexfreundlich, erfordern aber eine zentrale Koordination (die Datenbank) für die Zuweisung — was in verteilten Systemen scheitert und Zeilenzählungen preisgibt. UUIDs (insbesondere v7 oder ULID) können clientseitig ohne Datenbankroundtrip generiert werden, was optimistische Einfügungen und verteilte Schreibvorgänge ermöglicht. Der Kompromiss ist der Speicherplatz (16 Byte vs. 4–8 Byte) und eine etwas geringere Indexlokalität für zufällige UUIDs (v4). UUID v7 und ULID lösen das Indexlokalitätsproblem durch Zeitstempel-Präfixe.
Was ist der Unterschied zwischen UUID v3 und UUID v5?
Sowohl UUID v3 als auch v5 sind deterministisch: Sie erzeugen immer dieselbe UUID für dasselbe Namespace-+Name-Paar, was sie für reproduzierbare IDs bei DNS-Einträgen, URLs oder Objektbezeichnern nützlich macht. Der einzige Unterschied ist der Hash-Algorithmus: v3 verwendet MD5 (128 Bit, Legacy), v5 verwendet SHA-1 (160 Bit, auf 128 Bit gekürzt). Für neue Projekte ist UUID v5 zu bevorzugen — SHA-1 ist stärker als MD5, auch wenn keine Version als kryptografischer Hash verwendet wird.