UUID, ULID, Nanoid: Welche eindeutige ID sollten Sie 2026 wählen?
Zufälliger UUID v4, sortierbare UUID v7 und ULID, kompakter Nanoid: Vergleich und Online-Generatoren für Primärschlüssel und öffentliche IDs.
Zufällig, sortierbar oder kompakt: drei verschiedene Aufgaben für eine Zeichenkette
Ein einfacher Auto-Increment verrät, wie viele Zeilen eine Tabelle hat, lässt sich schlecht zwischen mehreren gleichzeitig schreibenden Servern koordinieren und ist erratbar — die ID 1042 legt nahe, dass es eine ID 1041 gibt. Deshalb erzeugen Anwendungen IDs client- oder serverseitig ohne zentralen Zähler. Aber „eindeutig und unvorhersehbar" bedeutet je nach Format nicht dasselbe. Der UUID-Generator erzeugt eine rein zufällige UUID v4, eine UUID v7, deren führende Bits einen Zeitstempel kodieren (also sortierbar ist), oder die nil-UUID zu Testzwecken. Der ULID-Generator verfolgt dasselbe Ziel wie UUID v7 — eine nach Erstellungszeit sortierbare ID — mit einer kürzeren Base32-Schreibweise. Der Nanoid-Generator verzichtet ganz auf den eingebetteten Zeitstempel, um die Zeichenkettenlänge bei gegebenem Entropie-Budget zu optimieren. Alle drei laufen vollständig im Browser und liegen zusammen im Hub der Entwickler-Utilities, neben dem Regex-Tester und dem Passwort-Generator.
Das richtige Werkzeug für den jeweiligen Kontext wählen
Prototyping, Tests und visuelle Prüfungen, bevor auch nur eine Zeile Server-Code geschrieben wird.
Der Online-Generator prototypt das Format; er ersetzt keine Generierung im Produktionsmaßstab.
Fehler, die in Produktion teuer werden
Ein mit UUID-v4-Werten gefüllter Primärschlüssel fügt jede neue Zeile an einer zufälligen Position im B-Tree-Index ein, was Seiten fragmentiert und Schreibvorgänge bei einer stark beschriebenen Tabelle verlangsamt. Das ist kein UUID-Problem im Allgemeinen, sondern ein Problem reiner Zufälligkeit: UUID v7 (RFC 9562) kodiert einen Millisekunden-Zeitstempel in den führenden 48 Bits und füllt den Rest zufällig auf, ULID macht dasselbe in Base32. Beide hängen sich ans Ende des Index an, wie ein Auto-Increment, ohne einen nutzbaren Zähler preiszugeben. Der UUID-Generator wechselt von v4 zu v7, ohne die Feldform zu ändern (36 Zeichen mit Bindestrichen); der ULID-Generator bietet die kürzere 26-Zeichen-Alternative.
Ein Auto-Increment durch UUID, ULID oder Nanoid zu ersetzen verhindert triviales Durchprobieren (?id=124, dann 125…), prüft aber niemandes Berechtigung: Eine über einen anderen Kanal erlangte ID — geteilter Link, Log-Zeile, Referrer-Header — bleibt lesbar, wenn die API den Besitz der Ressource nicht kontrolliert. ULID hat ein zusätzliches Problem: Die ersten 10 Zeichen kodieren den Erstellungszeitstempel im Klartext. Für einen Primärschlüssel unbedenklich, für ein Token, das opak bleiben soll, nicht — wer die Erstellungszeit ungefähr kennt, verkleinert den Suchraum, noch bevor er den zufälligen Teil angreift.
Die Kollisionsresistenz eines Nanoid hängt vollständig vom Produkt Größe × Alphabet ab. Die Voreinstellung des Werkzeugs (21 Zeichen über dem 64-Zeichen-url-Alphabet) zielt bei realistischer Generierungsrate auf eine Kollisionswahrscheinlichkeit ähnlich einer UUID v4 — aber jedes Preset ändert diese Rechnung. Der Wechsel zum Alphabet „numeric" (10 Symbole) oder eine Verkürzung auf 6-8 Zeichen für einen kürzeren Slug kann den ID-Raum um mehrere Größenordnungen verkleinern, ohne dass etwas darauf hinweist außer dem live angezeigten Entropiezähler neben dem Größenfeld.
Die Formatauswahl des UUID-Werkzeugs (einfach, geschweifte Klammern, urn:uuid:) und der Groß-/Kleinschreibungsschalter ändern die Textdarstellung, nicht die zugrunde liegenden 128 Bits — aber eine Spalte mit reinem String-Vergleich weiß nicht, dass {550e8400-…} und urn:uuid:550e8400-… dieselbe UUID bezeichnen, ohne vorherige Normalisierung. Dieselbe Logik gilt für ULID: Crockford-Base32 ist beim Dekodieren als groß-/kleinschreibungsunabhängig definiert, eine UNIQUE-Constraint auf einer Zeichenkette dagegen nicht.
Format, Größe, Sortierung: was die vier Varianten wirklich unterscheidet
Dasselbe Ziel — Eindeutigkeit ohne zentralen Koordinator — vier verschiedene Formen.
Die realen Optionen jedes Werkzeugs, wie sie heute existieren.
Drei konkrete Situationen, in denen die Formatwahl messbare Auswirkungen hat.
Generieren, anpassen, kopieren
Im UUID-Generator aktualisiert sich die Liste, sobald Sie eine Option ändern — es gibt keinen separaten „Generieren"-Button. Im ULID-Generator erscheint der dekodierte Zeitstempel jeder ID direkt unter der erzeugten Zeile.
Schritt 1 — Version oder Sortieroption wählen
UUID: v4 für reine Zufälligkeit, v7 für Sortierbarkeit, nil für die Test-UUID aus lauter Nullen (die Anzahl wird dann auf 1 erzwungen). ULID: monotonen Modus aktivieren, wenn mehrere IDs innerhalb derselben Millisekunde erzeugt werden und eine garantierte Reihenfolge nötig ist.
Schritt 2 — Bindestriche, Groß-/Kleinschreibung und Format anpassen
Bei UUID erzwingt die Wahl des Formats urn:uuid: automatisch Bindestriche und deaktiviert den Schalter für Groß-/Kleinschreibung. Bei ULID sind Großbuchstaben standardmäßig aktiv; die Crockford-Base32-Dekodierung bleibt auch in Kleinbuchstaben korrekt.
Schritt 3 — Anzahl (1 bis 50) einstellen und kopieren
Kopieren Sie die gesamte Liste auf einmal, laden Sie sie als .txt herunter, oder kopieren Sie mit dem Button je Zeile einzeln.
Der Nanoid-Generator zeigt die Entropie in Bits live an, sobald Sie Größe oder Alphabet ändern, damit Sie sie nie von Hand berechnen müssen.
Dieselben Formate serverseitig, in Node
Node stellt crypto.randomUUID() nativ für eine UUID v4 bereit, ganz ohne Abhängigkeit. Das eingebaute crypto-Modul erzeugt kein v7 — ein kleines npm-Paket wie uuid übernimmt die sortierbare Variante.
Einfaches Beispiel
Node hat keine eingebaute ULID-Unterstützung. Das Paket ulid bietet Generierung und Dekodierung des eingebetteten Zeitstempels.
Einfaches Beispiel
Das Paket nanoid entspricht dem Standard-url-Alphabet und der Standardgröße des Werkzeugs (21 Zeichen), mit customAlphabet für ein maßgeschneidertes Alphabet oder eine andere Größe.
Einfaches Beispiel
Keine Installation, keine Datenübertragung, bis zu 50 IDs pro Durchgang, vollständige Formatoptionen für alle drei Formate. Kompromiss: keine Generierung mit hohem Durchsatz im Browser, keine Monotonie-Garantie über mehrere Tabs oder Prozesse hinweg, und ein benutzerdefiniertes Nanoid-Alphabet auf 256 Zeichen begrenzt. Nutzen Sie die Seiten, um ein Schema zu entwerfen oder Fixtures zu erzeugen; behalten Sie uuid, ulid und nanoid serverseitig für die Produktion.
Fazit
Es gibt keinen absolut „besten" Bezeichner. UUID v4 bleibt die richtige Wahl für eine rein opake ID ohne Sortieranforderung und mit der breitesten nativen Unterstützung. UUID v7 oder ULID übernehmen, sobald die Einfügereihenfolge für die Indexleistung oder für eine anwendungsseitige Sortierung ohne dedizierte created_at-Spalte zählt. Nanoid zielt auf die kürzestmögliche Zeichenkette bei gegebenem Entropie-Budget, besonders in einer URL. Keines der drei ersetzt eine serverseitige Autorisierungsprüfung, und keines ist für Generierung mit hohem Durchsatz im Browser gedacht — dafür gibt es die Server-Bibliotheken uuid, ulid und nanoid. Wandern diese IDs durch die JSON-Nutzlast einer API, passt der Leitfaden zur Optimierung einer JSON-REST-API gut dazu, ebenso der JSON-Schema-Validator, um die erwartete Form eines id-Felds zu prüfen.
Verwandte Artikel
MD5- oder SHA-Digest berechnen oder eine Nachricht per HMAC signieren — im Browser. Hex, Base64 oder Base64URL, lokale Text-Prüfsummen und Webhooks.
Kein SSH und kein nginx für ein Next.js-Sideproject. Vergleich von Railway, Render, Vercel und einem VPS — dann aus Git deployen, nachdem Assets im Browser minifiziert wurden.
Text, Datei oder Bild im Browser nach Base64 wandeln (und zurück) — Data-URI, E-Mail-Anhang, JWT-Segment. 100 % lokal, keine Verschlüsselung.