Was ist eine ULID? Der sortierbare Unique Identifier, erklärt

Jede zufällige UUIDv4, die Sie als Primärschlüssel einfügen, landet an einer unvorhersehbaren Stelle im Datenbankindex. Wiederholen Sie das ein paar Millionen Mal, fragmentiert der Index, der Cache wird überlastet, und Schreibvorgänge werden langsamer. Eine ULID behebt das, ohne aufzugeben, was Sie an UUIDs schätzen: Sie können sie weiterhin überall erzeugen, ganz ohne zentralen Koordinator, doch sie landet in zeitlicher Reihenfolge, statt sich zu verstreuen.

Wie also sortiert sich eine 26 Zeichen lange Zeichenkette von selbst nach Zeit? Das ist der gesamte Trick, und es lohnt sich, ihn zu verstehen, bevor Sie zu einer ULID greifen.

Eine ULID (Universally Unique Lexicographically Sortable Identifier) ist ein 128-Bit-Identifier, geschrieben als 26 Crockford-Base32-Zeichen. Die ersten 10 Zeichen kodieren einen Zeitstempel in Millisekunden, die letzten 16 kodieren Zufallsbits, sodass später erzeugte ULIDs als reine Zeichenketten verglichen stets nach früheren einsortiert werden. Es ist ein sortierbarer Unique Identifier, den Sie offline erzeugen können.

Dieser Leitfaden zerlegt das in seine Teile: den Aufbau Zeichen für Zeichen entschlüsselt, den Beweis, dass sie wirklich sortiert, die B-Baum-Mathematik hinter dem Datenbankvorteil und einen ehrlichen Blick darauf, was der eingebettete Zeitstempel preisgibt. Sie können das Ganze mit einem echten Wert im ULID-Generator nachverfolgen, während Sie lesen: erzeugen Sie eine, dekodieren Sie sie, wandeln Sie sie in eine UUID um.

Was ist eine ULID?

Eine ULID (Universally Unique Lexicographically Sortable Identifier) ist ein 128-Bit-Identifier, der als besser sortierbare, kompaktere Alternative zu einer UUID entworfen wurde. Sie wird als 26 Zeichen in Crockford Base32 geschrieben: Die ersten 10 enthalten einen 48-Bit-Zeitstempel in Millisekunden seit der Unix-Epoche, die übrigen 16 enthalten 80 Bit Zufall. Weil die Zeit zuerst kommt, sortiert die Zeichenkette chronologisch.

Diese letzte Eigenschaft ist der Grund, warum das Format überhaupt existiert. UUIDv4 ist vollständig zufällig, was großartig für die Eindeutigkeit ist, aber bedeutet, dass zwei im Abstand einer Sekunde erzeugte IDs keinerlei Beziehung zueinander haben. ULIDs behalten das koordinationsfreie, überall-erzeugbare Modell und legen die Zeitsortierung obendrauf, sodass eine Spalte aus ULIDs ganz ohne Zusatzaufwand auf natürliche Weise nach Erstellungszeit sortiert ist.

Hier das Format auf einen Blick:

Eigenschaft	Wert
Bits	128
Kodierung	26 Crockford-Base32-Zeichen
Aufbau	48-Bit-Zeitstempel + 80 Bit Zufall

Der Rest dieses Artikels füllt aus, wie jeder Teil funktioniert. Die Kodierung und die Sortierbarkeit bekommen eigene Abschnitte zu Base32 und zum Sortierungsbeweis. Zuerst aber der Aufbau.

Aufbau einer ULID: 48 Bit Zeit + 80 Bit Zufall

Die 26 Zeichen einer ULID teilen sich sauber in zwei Hälften. Die ersten 10 Zeichen sind der Zeitstempel, die letzten 16 der Zufallsteil. Legt man das kanonische Beispiel aus, ist die Grenze offensichtlich:

01ARYZ6S41   TSV4RRFFQ69G5FAV
└────────┘   └──────────────┘
 10 chars        16 chars
48-bit ms      80-bit random
timestamp

Zwei Komponenten, zwei Aufgaben. Die eine hält fest, wann; die andere garantiert Eindeutigkeit. Beide lassen sich entschlüsseln.

Der 48-Bit-Zeitstempel (erste 10 Zeichen)

Die führenden 10 Zeichen kodieren eine 48-Bit-Ganzzahl: die Anzahl der Millisekunden seit der Unix-Epoche zum Zeitpunkt, an dem die ULID erzeugt wurde. Nehmen Sie das kanonische Beispiel direkt aus der Spezifikation:

01ARYZ6S41  ->  1469918176385 ms  ->  2016-07-30T22:36:16.385Z

Das ist eine echte, umkehrbare Dekodierung – fügen Sie 01ARYZ6S41TSV4RRFFQ69G5FAV in einen Decoder ein, und Sie erhalten genau 2016-07-30T22:36:16.385Z zurück. Die Zeitkomponente sind reine Daten, kein Hash, deshalb kostet ihr Auslesen nichts.

Ein kleines Detail, über das viele stolpern: Das erste Zeichen einer ULID liegt immer zwischen 0 und 7. Ein Crockford-Zeichen hält 5 Bit, und 48 Bit ist kein Vielfaches von 5 – der Zeitstempel belegt die unteren 48 der 50 Bit, die 10 Zeichen tragen können, sodass die obersten 2 Bit des ersten Zeichens dauerhaft null sind. Zwei Nullbits begrenzen den Wert dieses Zeichens auf 7. Wenn Sie je eine ULID sehen, die mit 8 oder höher beginnt, ist sie fehlerhaft.

Die 80 Bit Zufall (letzte 16 Zeichen)

Die übrigen 16 Zeichen tragen 80 Bit Zufall, und aus dieser Hälfte kommt die Eindeutigkeit. Die Bits sollten aus einer kryptografisch sicheren Quelle stammen – crypto.getRandomValues im Browser, nicht Math.random. Der Unterschied ist entscheidend: Math.random ist vorhersagbar genug, dass ein Angreifer Werte erraten oder Kollisionen erzwingen könnte, ein CSPRNG dagegen nicht.

Wie viel Raum sind 80 Bit? Etwa 1,2 × 10²⁴ mögliche Werte, und das pro Millisekunde. Selbst wenn Sie Millionen ULIDs innerhalb einer einzigen Millisekunde erzeugen, bleibt die Wahrscheinlichkeit, dass zwei dieselben 80 Bit ziehen, verschwindend gering. Anders als der Zeitstempel trägt diese Hälfte keine dekodierbare Bedeutung – sie ist Rauschen, dessen einziger Zweck es ist, jede ULID eindeutig zu machen.

Crockfords Base32: Warum ULIDs I, L, O und U weglassen

ULIDs werden mit Crockfords Base32 kodiert, einem Alphabet aus 32 Symbolen: den Ziffern 0–9 und den Buchstaben A–Z, von denen vier entfernt wurden.

0123456789ABCDEFGHJKMNPQRSTVWXYZ

Die fehlenden Buchstaben sind I, L, O und U. Drei werden gestrichen, weil sie wie Ziffern aussehen – I und L ähneln 1, O ähnelt 0 –, sodass ein Mensch, der eine ULID vom Bildschirm abliest, einen Buchstaben nicht mit einer Zahl verwechseln kann. Die Kehrseite ist nachsichtige Eingabe: Ein konformer Decoder bildet I und L zurück auf 1 und O auf 0 und behandelt die gesamte Zeichenkette ohne Berücksichtigung der Groß-/Kleinschreibung. U wird gesondert ausgeschlossen, um zu vermeiden, dass versehentlich anstößige Wörter buchstabiert werden.

Die Bit-Mathematik ist der andere Grund. Jedes Base32-Zeichen kodiert 5 Bit, während ein Hexadezimalzeichen nur 4 kodiert. Packt man 128 Bit mit 5 Bit pro Zeichen, braucht man 26; packt man dieselben 128 Bit mit je 4 Bit – so wie es eine UUID tut –, braucht man 32 plus vier Bindestriche, also 36 Zeichen. Eine ULID ist also spürbar kürzer als eine UUID und passt ohne Bindestriche direkt in eine URL, einen Dateinamen oder einen Header, ganz ohne Escaping.

Crockfords Base32 ist ein Alphabet aus 32 Symbolen (0–9 und A–Z minus I, L, O, U), das 5 Bit pro Zeichen kodiert. ULIDs nutzen es, um 128 Bit in 26 Zeichen zu packen, die unabhängig von Groß-/Kleinschreibung und URL-sicher sind, und – entscheidend – das Alphabet ist aufsteigend angeordnet, was die kodierte Zeichenkette genauso sortieren lässt wie die rohen Bits.

Warum ULIDs nach Zeit sortieren

Viele Artikel sagen Ihnen, dass ULIDs nach Zeit sortieren. Weniger zeigen warum. Das Argument ruht auf zwei Tatsachen, die Sie bereits kennen: Der Zeitstempel ist der höchstwertige Teil des Werts, und Crockfords Alphabet ist aufsteigend angeordnet.

Verbindet man beides, erhält man eine Kette von Äquivalenzen:

string compare  ==  128-bit integer compare  ==  creation-time compare

Lesen Sie sie von links nach rechts. Vergleicht man zwei ULIDs Zeichen für Zeichen (so wie eine Zeichenkettensortierung arbeitet), ergibt das dieselbe Antwort wie der Vergleich ihrer zugrunde liegenden 128-Bit-Ganzzahlen, weil das Alphabet ordnungserhaltend ist – ein „höheres” Zeichen bedeutet immer einen höheren Wert. Der Vergleich der 128-Bit-Ganzzahlen ergibt dieselbe Antwort wie der Vergleich der Erstellungszeiten, weil der Zeitstempel in den höchstwertigen Bits sitzt und so den Vergleich dominiert; der zufällige Schwanz bricht nur Gleichstände innerhalb derselben Millisekunde auf. Zeichenketten-Reihenfolge, Bit-Reihenfolge und Zeit-Reihenfolge sind dieselbe Reihenfolge.

Eine kurze Demonstration. Zwei ULIDs, im Abstand einer Millisekunde erzeugt:

01ARYZ6S41...   (created at T)
01ARYZ6S42...   (created at T + 1 ms)

Das zehnte Zeichen springt von 1 auf 2, und eine einfache Textsortierung setzt die zweite nach der ersten – keine Zeitstempel-Spalte, kein spezieller Vergleicher. Der praktische Gewinn, den der nächste Abschnitt ausführt, ist eine Zeile: ORDER BY id liefert Zeilen in chronologischer Reihenfolge, ohne zusätzlichen Index.

ULIDs als Datenbank-Primärschlüssel: B-Baum-Lokalität

Hier verdienen ULIDs ihren Platz. Die meisten relationalen Datenbanken speichern einen Primärschlüsselindex als B-Baum, und wo ein neuer Schlüssel in diesem Baum landet, entscheidet, wie teuer das Einfügen ist.

Eine zufällige UUIDv4 landet bei jedem Einfügen an einer unvorhersehbaren Stelle:

UUIDv4: Jeder neue Schlüssel zielt auf eine zufällige Blattseite. Die Seite ist oft voll, also teilt die Engine sie, kopiert die Hälfte der Zeilen anderswohin und verschmutzt Seiten überall im Baum. Über Millionen von Zeilen fragmentiert das den Index, verdrängt nützliche Seiten aus dem Puffer-Cache und drückt den Schreibdurchsatz. (Für die harten Zahlen zu Index-Seitenteilungen – typischerweise ein Unterschied von 2–10× bei schreiblastigen Tabellen – siehe den Vergleichsleitfaden.)

Eine zeitpräfixierte ULID landet jedes Mal am Ende:

ULID: Weil die hohen Bits ein Zeitstempel sind, ist jeder neue Schlüssel größer als der letzte, sodass er an oder nahe der rechten Kante des Index angehängt wird. Einfügungen bleiben sequenziell, Seitenteilungen verschwinden nahezu, der Index bleibt kompakt, und ein Bereichsscan über ein Zeitfenster liest einen zusammenhängenden Lauf von Seiten.

Sie erhalten die koordinationsfreie Erzeugung einer UUID mit der Einfüge-Lokalität einer Auto-Increment-Ganzzahl – ohne einen erratbaren sequenziellen Zähler offenzulegen, da der zufällige Schwanz den genauen nächsten Wert weiterhin verbirgt.

Speicher-Tipp: Speichern Sie die 128 Bit als 16 binäre Bytes – eine uuid-Spalte in PostgreSQL, BINARY(16) in MySQL – nicht als 26 Zeichen langes Textfeld, das Platz verschwendet und den Index aufbläht. Kodieren Sie nur an den Rändern zur Base32-Zeichenkette, wo ein Mensch oder eine URL sie sieht. Der Convert-Reiter des Generators wird eine ULID in eine UUID umwandeln genau dafür, da die beiden Formen dieselben 128 Bit sind.

Monotone ULIDs: Strikte Ordnung innerhalb einer Millisekunde

Der Sortierbarkeitsbeweis hat eine ehrliche Lücke: Innerhalb einer einzigen Millisekunde sind einfache ULIDs nicht strikt geordnet. Sie teilen sich dasselbe 10 Zeichen lange Zeitpräfix, aber ihre 80-Bit-Zufallsschwänze werden unabhängig gezogen, sodass es im Wesentlichen ein Münzwurf ist, welche von zwei ULIDs derselben Millisekunde zuerst sortiert. Für die meisten Anwendungen ist das in Ordnung. Wenn Sie strikte Ordnung auch bei Subdurchschnittsmillisekunden-Raten brauchen, ist es das nicht.

Monotone Erzeugung schließt die Lücke. Die Regel ist einfach: Die erste ULID in einer gegebenen Millisekunde erhält wie üblich frischen Zufall, und jede spätere ULID in derselben Millisekunde wird erzeugt, indem der vorherige 80-Bit-Zufallswert genommen und um eins erhöht wird (behandelt als Big-Endian-Ganzzahl, mit Übertrag in höhere Bits bei Bedarf). Jeder Wert ist daher strikt größer als der vorhergehende.

Sie können es an einem innerhalb einer Millisekunde erzeugten Stapel sehen – nur das letzte Zeichen bewegt sich:

01KVT0F720ZK9N4T2QX7VR8WMC
01KVT0F720ZK9N4T2QX7VR8WMD
01KVT0F720ZK9N4T2QX7VR8WME

…WMC < …WMD < …WME, garantiert. Das ist immer dann wichtig, wenn Zeilen schneller erzeugt werden können, als die Millisekundenuhr tickt: Einfügungen mit hohem Durchsatz, Ereignisprotokolle, Nachrichten-IDs in einer engen Schleife. Wenn die Uhr zur nächsten Millisekunde voranschreitet, kehrt die Erzeugung zu frischem Zufall zurück, und der Zyklus wiederholt sich.

ULID vs. UUID: Wann was verwenden

Die Frage, mit der die meisten tatsächlich ankommen, lautet ULID vs. UUID. Hier der fokussierte Vergleich – ULID gegen die zwei UUID-Versionen, die Sie realistisch dagegen abwägen würden. (Für die vollständige Entscheidungsmatrix mit fünf Optionen einschließlich Snowflake und NanoID siehe den vollständigen Vergleich von ULID, UUID und Snowflake.)

Eigenschaft	ULID	UUIDv4	UUIDv7
Länge	26 Zeichen	36 Zeichen	36 Zeichen
Kodierung	Crockford Base32	Hex mit Bindestrichen	Hex mit Bindestrichen
Nach Zeit sortierbar?	Ja	Nein	Ja
Bettet Zeitstempel ein?	Ja (48-Bit-ms)	Nein	Ja (48-Bit-ms)
Standardisiert?	Community-Spezifikation	RFC 9562	RFC 9562
Am besten für	Kurze sortierbare IDs	Undurchsichtige zufällige IDs	Sortierbare IDs im UUID-Format

In Prosa: Greifen Sie zu einer ULID, wenn Sie die kürzeste, URL-sichere, sortierbare Zeichenkette wollen. Greifen Sie zu UUIDv4, wenn Sie einen undurchsichtigen, vollständig zufälligen Identifier ohne eingebettete Zeit wollen – zum Beispiel ein öffentliches Token, bei dem Sie lieber nicht preisgeben, wann es erstellt wurde. Greifen Sie zu UUIDv7, wenn Sie Zeitsortierung brauchen, aber im standardisierten UUID-Format bleiben müssen, mit Versions- und Variantenbits an ihren festen Positionen und einer nativen uuid-Spalte, in die Sie sie ablegen können.

Alle drei sind 128 Bit, daher ist die ULID-↔-UUID-Umwandlung in beide Richtungen verlustfrei. Die Beziehung zwischen ULID und ulid vs uuid v7 ist enger, als sie aussieht: UUIDv7 ist im Wesentlichen die von der IETF standardisierte Auslegung derselben zeitpräfixierten Idee, die ULID begründet hat. Wenn Sie neu bei UUIDs insgesamt sind, beginnen Sie zuerst mit den Grundlagen und kommen Sie dann zu diesem Vergleich zurück.

Der Datenschutz-Kompromiss: ULIDs geben ihre Erstellungszeit preis

Der eingebettete Zeitstempel ist ein Feature und ein Leck, je nachdem, wer die ID liest. Jeder, der eine ULID besitzt, kann in einem Schritt den Zeitstempel dekodieren und die exakte Millisekunde erfahren, in der der Datensatz erstellt wurde – ganz ohne Zugriff auf Ihre Datenbank.

Innerhalb Ihrer eigenen Systeme ist das nur von Vorteil: sofortige Prüfbarkeit, kostenlose Sortierung, einfaches Debugging. Bei einem nach außen gerichteten Identifier ist es eine echte Offenlegung. Die Erstellungszeit kann für sich genommen geschäftssensibel sein, und eine Handvoll über die Zeit gesammelter ULIDs geben Ihre Erstellungsrate preis, also wie viele Bestellungen, Konten oder Nachrichten Sie pro Sekunde erzeugen. Genau die Art von Sache, die Wettbewerber und Scraper gern abschätzen.

Fairerweise ist das ein engeres Leck als bei UUIDv1, das historisch die MAC-Adresse der erzeugenden Maschine einbettete; eine ULID legt nur Zeit offen, niemals Hardware-Identität. Wägen Sie es dennoch ab. Die einfache Gegenmaßnahme: ULIDs intern halten und für nach außen gerichtete IDs, bei denen die Reihenfolge keine Rolle spielt, eine vollständig zufällige UUIDv4 ausgeben.

Häufige Fallstricke bei ULIDs

Die meisten ULID-Probleme sind eine Handvoll vermeidbarer technischer Entscheidungen, keine Fehler im Format. Die wiederkehrenden:

• Annehmen, dass einfache ULIDs derselben Millisekunde geordnet sind. Sie teilen sich ein Zeitpräfix, haben aber unabhängige Zufallsschwänze, sodass ihre Reihenfolge undefiniert ist. Lösung: Verwenden Sie den monotonen Modus, wenn Sie strikte Ordnung bei Subdurchschnittsmillisekunden-Raten brauchen.
• Eine ULID als 26 Zeichen langen Text speichern. Das verschwendet Platz und bläht den Index auf. Lösung: Speichern Sie die 128 Bit als 16 Bytes (uuid / BINARY(16)) und kodieren Sie nur an den Rändern zu Base32.
• Erwarten, dass eine ULID→UUID-Umwandlung als v4 oder v7 gemeldet wird. Die Umwandlung kodiert dieselben Bits neu; sie setzt nicht die UUID-Versions- und Variantenfelder, sodass eine Bibliothek, die sie inspiziert, keine getaggte Version sieht. Lösung: Behandeln Sie das Ergebnis als undurchsichtigen 128-Bit-Wert oder erzeugen Sie eine echte UUIDv7, wenn Sie das Tag brauchen.
• Den Zufall mit Math.random füllen. Es ist vorhersagbar und kann kollidieren. Lösung: Verwenden Sie immer einen CSPRNG wie crypto.getRandomValues.
• ULIDs öffentlich offenlegen, ohne das Zeitstempel-Leck abzuwägen. Siehe den Datenschutz-Abschnitt oben. Lösung: interne ULIDs, zufällige UUIDv4 für öffentliche IDs.
• I, L, O oder U von Hand in eine ULID tippen. Diese Buchstaben sind nicht im Alphabet, und das Neutippen lädt zu Fehlern ein. Lösung: ULIDs kopieren, nicht neu tippen.

FAQ

Ist ULID ein offizieller Standard wie UUID?

Nein. ULID ist eine auf GitHub veröffentlichte Community-Spezifikation, kein IETF-RFC. Sie ist weit verbreitet und stabil, hat aber kein Standardisierungsgremium hinter sich. Wenn Sie einen standardisierten, zeitlich geordneten Identifier brauchen, wendet UUIDv7 (RFC 9562) dieselbe Idee innerhalb des offiziellen UUID-Formats an.

Wie viele Zeichen hat eine ULID, und warum ist sie kürzer als eine UUID?

26 Zeichen, gegenüber den 36 einer UUID. ULID verwendet Crockford Base32, das 5 Bit pro Zeichen packt; die Hexadezimal-Kodierung einer UUID packt nur 4 Bit und fügt vier Bindestriche hinzu. Dieselben 128 Bit brauchen daher in Base32 weniger Zeichen – und keines davon braucht URL-Escaping.

Können zwei ULIDs jemals kollidieren?

Praktisch nie. Innerhalb einer Millisekunde hat eine ULID 80 Zufallsbits – etwa 1,2 × 10²⁴ Möglichkeiten –, sodass selbst das Erzeugen von Millionen pro Millisekunde die Kollisionswahrscheinlichkeit verschwindend gering hält. Die eine Voraussetzung ist, dass ein kryptografisch sicherer RNG den Zufall füllt; Math.random macht die Garantie hinfällig.

Kann ich ULIDs in PostgreSQL oder MySQL speichern?

Ja. Eine ULID ist 128 Bit, also wandeln Sie sie in die UUID-Form um und speichern Sie sie in einer uuid-Spalte (PostgreSQL) oder BINARY(16) (MySQL), und rendern Sie die Base32-Zeichenkette nur an den Rändern. Es gibt keinen nativen ULID-Spaltentyp, aber die UUID-Darstellung kostet dieselben 16 Bytes und hält den Index kompakt.

Sind ULIDs von der Groß-/Kleinschreibung abhängig?

Die kanonische Form ist Großbuchstaben, aber Crockford Base32 ist bei der Eingabe unabhängig von der Groß-/Kleinschreibung: Ein Decoder liest Kleinbuchstaben genauso und bildet I/L auf 1 und O auf 0 ab. Um Überraschungen bei Gleichheitsprüfungen und Indizes zu vermeiden, normalisieren Sie auf eine einheitliche Schreibung, bevor Sie speichern oder vergleichen.

Wird der 48-Bit-Zeitstempel jemals ablaufen?

Nicht für sehr lange Zeit. 48 Bit Millisekunden reichen bis zum Jahr 10889, bevor der Zähler überläuft, sodass die Zeitstempelkomponente für jede reale Anwendung praktisch zukunftssicher ist. Sie werden das System, die Sprache und die Datenbank längst ersetzt haben, bevor dem Format der Platz ausgeht.

Kann ich ULIDs im Browser oder auf dem Mobilgerät ohne Server erzeugen?

Ja – das ist ein Kernvorteil. ULIDs brauchen keinen zentralen Koordinator, sodass jeder Knoten, Edge-Worker, Browser oder jedes Gerät eine aus seiner Uhr plus einem sicheren RNG erzeugen kann. Auf verschiedenen Maschinen erzeugte Werte sortieren danach trotzdem gemeinsam nach Zeit, weil der Zeitstempel in der ID selbst steckt.

Fazit

ULIDs lösen ein konkretes, reales Problem – zufällige Schlüssel, die Ihren Index fragmentieren – ohne die dezentrale Erzeugung wegzunehmen. Die Mechanik ist es wert, im Kopf zu behalten:

• Eine ULID ist ein 48-Bit-Millisekunden-Zeitstempel + 80 Bit Zufall, kodiert als 26 Crockford-Base32-Zeichen.
• Sie sortiert nach Zeit, weil der Zeitstempel die höchstwertige Komponente ist und das Alphabet ordnungserhaltend – Zeichenketten-Reihenfolge gleich Zeit-Reihenfolge.
• Diese Ordnung verschafft einem B-Baum die Einfüge-Lokalität, die einer zufälligen UUIDv4 fehlt, hält Schreibvorgänge schnell und den Index kompakt.
• Verwenden Sie den monotonen Modus, wenn Sie strikte Ordnung für in derselben Millisekunde erzeugte IDs brauchen.
• Wägen Sie das Zeitstempel-Leck ab, bevor Sie ULIDs auf nach außen gerichteten Identifiern offenlegen.
• Wählen Sie stattdessen UUIDv7, wenn Sie im standardisierten UUID-Format bleiben müssen.

Wenn Sie bereit sind, es in die Praxis umzusetzen, öffnen Sie den ULID-Generator, um ULIDs vollständig in Ihrem Browser zu erzeugen, zu dekodieren und umzuwandeln – kein Server, kein Upload, nichts gespeichert.