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ällige, sortierbare und kompakte IDs für verschiedene Aufgaben
Ein einfacher Auto-Increment verrät, wie viele Zeilen eine Tabelle hat. Er lässt sich schlecht zwischen mehreren Servern abstimmen, die gleichzeitig schreiben. Er ist auch leicht zu erraten: Wer die ID 1042 sieht, vermutet eine ID 1041. Deshalb erzeugen Anwendungen IDs im Client oder auf dem Server, ohne zentralen Zähler. „Eindeutig und unvorhersehbar“ bedeutet aber nicht in jedem Format dasselbe. Der UUID-Generator erzeugt eine zufällige UUID v4, eine UUID v7, die mit einem Zeitstempel beginnt, oder die Nil-UUID für Tests. Der ULID-Generator verfolgt dasselbe Ziel wie UUID v7, eine nach Erstellungszeit sortierbare ID, mit einer kürzeren Base32-Zeichenkette. Der Nanoid-Generator verzichtet auf den Zeitstempel und nutzt jedes Zeichen für Zufall. So wird die Zeichenkette bei gleicher Entropie kürzer. Alle drei laufen 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 dient zum Ausprobieren des Formats. Für die Erzeugung im Produktionsmaßstab ist er nicht gedacht.
uuid, ulid, nanoid unter Node) kommt ohne Browser ausFehler, die in Produktion teuer werden
Ein Primärschlüssel aus UUID-v4-Werten fügt jede neue Zeile an einer zufälligen Stelle im B-Tree-Index ein. Bei einer stark beschriebenen Tabelle fragmentiert das die Seiten und bremst Schreibvorgänge. Die Ursache ist reiner Zufall, nicht die UUID an sich. UUID v7 (RFC 9562) legt einen Millisekunden-Zeitstempel in die ersten 48 Bit und füllt den Rest mit Zufallsbits. ULID setzt dieselbe Idee in Base32 um. Neue Werte landen dann am Ende des Index, wie bei einem Auto-Increment, ohne einen nutzbaren Zähler preiszugeben. Laut RFC 9562 kann der Unterschied eine Größenordnung oder mehr betragen. Der UUID-Generator wechselt von v4 zu v7, ohne die Form des Felds zu ändern (36 Zeichen mit Bindestrichen). Der ULID-Generator bietet die kürzere Variante mit 26 Zeichen.
Wer einen Auto-Increment durch UUID, ULID oder Nanoid ersetzt, verhindert einfaches Durchprobieren (?id=124, dann 125…). Eine Berechtigungsprüfung ersetzt das nicht. Eine anderswo bekannt gewordene ID (geteilter Link, Log-Zeile, Referer-Header) bleibt lesbar, wenn die API den Besitz der Ressource nicht prüft. ULID bringt ein eigenes Problem mit. Die ersten 10 Zeichen verraten den Erstellungszeitpunkt im Klartext. Für einen Primärschlüssel ist das harmlos. Für ein Token, das opak bleiben soll, nicht: Wer den Erstellungszeitpunkt ungefähr kennt, verkleinert den Suchraum, bevor er den Zufallsteil angreift.
Die Kollisionsresistenz eines Nanoid hängt von Größe und Alphabet zugleich ab. Die Voreinstellung des Werkzeugs, 21 Zeichen aus dem URL-sicheren Alphabet mit 64 Symbolen, trägt 126 Zufallsbits, gegenüber 122 bei einer UUID v4. Jede andere Einstellung ändert diese Rechnung. Bei 8 Zeichen aus demselben Alphabet erreicht die Wahrscheinlichkeit mindestens einer Kollision nach etwa 2,4 Millionen IDs 1 %. Das Alphabet „Numerisch“ (10 Symbole) verkleinert den Raum ebenfalls: 21 Ziffern ergeben rund 70 Bit. Nichts warnt Sie davor, außer der Entropie in Bits im Tooltip neben dem Feld „Größe“.
Die Formatauswahl des UUID-Werkzeugs (einfach, geschweifte Klammern, URN) und der Schalter für Großbuchstaben ändern die Schreibweise, nicht die 128 Bit dahinter. Eine Spalte mit reinem Textvergleich erkennt nicht, dass {550e8400-…} und urn:uuid:550e8400-… dieselbe UUID bezeichnen, solange niemand normalisiert. Bei ULID lauert dieselbe Falle. Crockford-Base32 ignoriert beim Dekodieren die Groß- und Kleinschreibung, eine UNIQUE-Constraint auf einer Textspalte beachtet sie dagegen oft, wie PostgreSQL standardmäßig.
Format, Größe und Sortierung der vier Varianten
Dasselbe Ziel, Eindeutigkeit ohne zentralen Koordinator, in vier verschiedenen 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 wird die Liste neu erzeugt, sobald Sie eine Option ändern. Eine eigene Schaltfläche „Generieren“ gibt es nicht. Im ULID-Generator erscheint der dekodierte Zeitstempel jeder ID direkt unter ihrer Zeile.
1. Version oder Option „Monoton“ wählen
Bei UUID liefert v4 reinen Zufall, v7 eine zeitliche Reihenfolge und nil die UUID aus lauter Nullen, dann immer genau eine. Die v7-IDs einer Liste teilen meist dieselbe Millisekunde und sind untereinander nicht sortiert. Bei ULID teilen alle IDs einer Liste dieselbe Millisekunde und erscheinen in zufälliger Reihenfolge. Schalten Sie „Monoton“ ein, um eine streng aufsteigende Liste zu erhalten.
2. Bindestriche, Schreibweise und Format anpassen
Bei UUID erzwingt das Format URN Bindestriche und Kleinbuchstaben und sperrt beide Schalter. Bei ULID sind Großbuchstaben voreingestellt; Crockford-Base32 lässt sich in Kleinbuchstaben genauso dekodieren.
3. Anzahl (1 bis 50) einstellen und kopieren
Kopieren Sie die ganze Liste auf einmal, laden Sie sie als .txt-Datei herunter oder kopieren Sie eine einzelne Zeile über ihre Kopierschaltfläche.
Der Nanoid-Generator zeigt die Entropie in Bits im Tooltip der Schaltfläche neben „Größe“. Der Wert folgt jeder Änderung von Größe oder Alphabet, Sie müssen ihn also nicht von Hand berechnen.
Dieselben Formate serverseitig, in Node
Node liefert crypto.randomUUID() für eine UUID v4, ohne Abhängigkeit. Seit Node 24.16 und 26.1 erzeugt crypto.randomUUIDv7() auch eine v7. Bei älteren Versionen übernimmt das kleine Paket uuid die sortierbare Variante, wie im Beispiel.
Einfaches Beispiel
Node hat keine eingebaute ULID-Unterstützung. Das Paket ulid erzeugt ULIDs und dekodiert ihren eingebetteten Zeitstempel.
Einfaches Beispiel
Das Paket nanoid nutzt dasselbe URL-sichere Alphabet und dieselbe Standardgröße wie das Werkzeug (21 Zeichen). Seine Funktion customAlphabet nimmt ein eigenes Alphabet und eine eigene Größe an.
Einfaches Beispiel
Keine Installation, kein Upload, bis zu 50 IDs pro Liste und alle Formatoptionen der drei Werkzeuge. Dafür gibt es keine Erzeugung mit hohem Durchsatz im Browser und keine monotone Reihenfolge über Listen, Tabs oder Prozesse hinweg. Ein eigenes Nanoid-Alphabet ist auf 256 Zeichen begrenzt. Nutzen Sie die Seiten, um ein Schema zu entwerfen oder Fixtures zu erzeugen. In Produktion gehören uuid, ulid und nanoid auf den Server.
Zusammenfassung
Kein Bezeichner passt für jeden Fall. UUID v4 bleibt die richtige Wahl für eine rein opake ID ohne Sortieranforderung, mit der breitesten nativen Unterstützung. UUID v7 oder ULID übernehmen, sobald die Einfügereihenfolge für die Indexleistung zählt oder eine Sortierung ohne eigene created_at-Spalte nötig ist. Nanoid liefert bei gegebener Entropie die kürzeste Zeichenkette, was in einer URL hilft. Keines der drei ersetzt eine serverseitige Autorisierungsprüfung. Für Erzeugung mit hohem Durchsatz im Browser ist auch keines gedacht, dafür gibt es die Server-Bibliotheken uuid, ulid und nanoid. Wandern diese IDs in der JSON-Nutzlast einer API, passt der Leitfaden zur Optimierung einer JSON-REST-API dazu. Der JSON-Schema-Validator prüft dann die erwartete Form eines id-Felds.
Eine ID im Browser generieren
uuid, ulid, nanoid), nicht der Browser-GeneratorVerwandte Artikel
Fügen Sie Token und JWKS ein und prüfen Sie eine RS256-, ES256- oder HS256-Signatur im Browser. Schlüsselwahl per kid, Fehler und zu prüfende Claims.
HTTP/2 und HTTP/3 ändern den Weg der Dateien, nicht ihre Größe. Messungen zu Größe, Kompilierzeit und Bundling zeigen, was Minifizierung noch bringt.
Rechnen Sie eine Unix-Epoche in ein lesbares Datum um und zurück, unterscheiden Sie Sekunden und Millisekunden und meiden Sie Zeitzonen-, JWT- und Zeitumstellungsfallen.