ULID-generator

ULID-generator: tijdsorteerbare, compacte identifiers zonder hyphen

Wat maakt deze ULID-generator anders?

Deze pagina produceert ULID’s in plaats van UUID’s, NanoID’s of andere formaten. Waar UUID v4 36 karakters telt (inclusief bindestrepen) en hoofdlettergevoelig is, levert ULID een string van precies 26 karakters op. Die karakters zijn allemaal afkomstig uit Crockfords base32-alfabet: de cijfers 0-9 en de letters A-Z, met uitzondering van I, L, O en U. Daardoor is een ULID case‑insensitive – een hoofdletter verschil doet er niet toe. En er staan geen hyphen in: de identificatie is direct klaar voor gebruik in URL’s, bestandsnamen of databasekolommen.

De eerste tien karakters coderen een timestamp met millisecondeprecisie (48 bits). De resterende zestien karakters zijn willekeurig (80 bits). Omdat de timestamp vooraan staat, zijn ULID’s lexicografisch sorteerbaar op aanmaaktijd. Dit is precies wat de pagina uniek maakt ten opzichte van de andere formaten op dezelfde tool: er zijn geen knoppen om hoofdletters of hyphen aan of uit te zetten, want die bestaan bij ULID simpelweg niet. De gegenereerde lijst is direct bruikbaar.

Interne structuur van een ULID: timestamp en willekeurig deel

Een ULID is een 128‑bits waarde, verdeeld in twee delen:

• Timestamp (48 bits) – opgeslagen in de eerste 10 karakters. De timestamp is het aantal milliseconden sinds het Unix‑tijdperk (1 januari 1970 UTC). Omdat 48 bits een bereik van ongeveer 8,9 miljoen jaar geven, is dit voor alle praktische doeleinden onuitputtelijk. De encoder gebruikt Crockfords base32 om deze 48 bits in 10 karakters te zetten.
• Willekeurig deel (80 bits) – opgeslagen in de laatste 16 karakters. Deze bits worden gegenereerd met crypto.getRandomValues() in de browser. Dat is sterke, cryptografische willekeur, precies zoals voor UUID v4 wordt vereist.

De combinatie levert een string op zoals 01ARZ3NDEKTSV4RRFFQ69G5FAV. De eerste tien (01ARZ3NDEK) geven bijvoorbeeld het tijdstip 1.468.794.705.000 ms (ongeveer juli 2016). De rest is uniek voor elke gegenereerde ID binnen die milliseconde.

Let op: de tool genereert tussen 1 en 100 ID’s per keer. Buiten die range wordt geen invoer geaccepteerd. De generator werkt volledig lokaal – er wordt niets naar een server gestuurd.

Crockfords base32: waarom hoofdletterongevoelig en zonder hyphen?

Crockford vond het base32‑alfabet uit om identificaties leesbaarder te maken. Het alfabet bevat 32 tekens: 0-9 en A-Z, maar laat I, L, O, U weg. Die letters worden vaak verward met 1, l, 0 of V. Daardoor is een ULID vrijwel foutvrij over te typen, ook als iemand hoofdletters en kleine letters door elkaar gebruikt. Een g en G worden als hetzelfde teken behandeld.

De pagina biedt dan ook geen opties voor upper‑ of lowercase. De gegenereerde strings worden in hoofdletters getoond, maar dat is slechts een weergavekeuze. Het feit dat er geen hyphen in zitten, vereenvoudigt kopiëren en plakken in programmeercode, databasequeries of configuratiebestanden. Geen UUID met vier streepjes, maar een aaneengesloten string van 26 tekens.

Deze eigenschappen maken ULID ook URL‑veilig volgens RFC 3986. Geen enkel teken in Crockfords base32 hoeft te worden gepercent‑encodeerd. Dat is handig voor API‑eindpunten of REST‑routes waar unieke parameters in de pad zitten.

Vergelijking met UUID v4 en UUID v7

Hieronder een overzicht van de belangrijkste verschillen:

UUID v7 (RFC 9562) lijkt qua opbouw op ULID, maar gebruikt nog steeds de klassieke hyphen‑notatie en is niet standaard case‑insensitive. In de praktijk betekent dit dat ULID korter is en minder problemen geeft met hoofdletterverwarring. De 80 random bits van ULID tegenover 74 bij v7 betekenen een kleine maar meetbare grotere random‑ruimte (2^80 versus 2^74). Dat verlaagt de kans op collisies bij hoge generatiesnelheden.

Sorteergedrag en gelijktijdigheid: wat gebeurt er in dezelfde milliseconde?

Omdat de timestamp de eerste 10 karakters bepaalt, staan ID’s die op verschillende momenten zijn gegenereerd altijd in oplopende tijdsvolgorde als je ze alfabetisch sorteert. Dit is ideaal voor database‑indexen: nieuwe rijen worden aan het einde van een B‑tree ingevoegd, wat fragmentatie vermindert en schrijfprestaties verbetert.

Het cruciale voorbehoud: ULID garandeert geen strikte volgorde voor ID’s die in exact dezelfde milliseconde worden gegenereerd. Binnen die milliseconde is de random component bepalend. Dus als je tien ID’s tegelijk aanmaakt, kunnen die in een willekeurige volgorde staan. De tool genereert de lijst in één batch, dus alle ID’s krijgen dezelfde timestamp (of quasi‑gelijktijdig). De volgorde in de uitvoer is de volgorde waarin de random bits gegenereerd zijn. Dat is toevallig, niet gesorteerd op geboorte.

Voor de meeste toepassingen is dit voldoende. Wil je een volledig monotone volgorde, dan moet je een gegenereerde ID pas gebruiken nadat de volgende milliseconde is ingegaan – of een ander schema zoals Twitter‑snowflake toepassen. ULID is ontworpen als een praktisch bruikbare identifier, niet als een gegarandeerde chronologische sequentie.

Kans op collisie en veiligheid van lokale generatie

De kans dat twee ULID’s botsen wordt bepaald door de 80 random bits. In de praktijk geldt: bij 1 miljard gegenereerde ID’s is de kans op één enkele collisie ongeveer 2 * 10^-18. Dat is verwaarloosbaar. Zelfs bij het genereren van 100 ID’s per milliseconde (de maximumcapaciteit van de tool) zou het vele miljarden jaren duren voordat een botsing statistisch waarschijnlijk wordt.

De generator gebruikt de ingebouwde browser‑API crypto.getRandomValues(), die cryptografisch sterke willekeur levert. Dit is een vereiste voor een productie‑identificatie, omdat zwakkere generatoren (zoals Math.random()) voorspelbaar kunnen zijn. Bovendien gebeurt alles lokaal: de opgevraagde ID’s worden nooit via het netwerk verstuurd. Dit is een belangrijk privacy‑ en beveiligingsvoordeel ten opzichte van online UUID‑diensten die de gegenereerde waarden naar een server loggen.

De tool vereist geen account, geen cookies en geen netwerkverbinding voor de generatie zelf. Zodra de pagina is geladen, werkt alles offline.

Praktisch gebruik: database‑indexen, API’s en URL‑veiligheid

ULID’s zijn bijzonder geschikt als primaire sleutel in relationele databases. Omdat ze oplopend zijn, wordt het invoegen van nieuwe rijen in een B‑tree (zoals die in MySQL InnoDB, PostgreSQL standaard) aan het einde van de boom gedaan. Dat vermindert page splits en indexfragmentatie aanzienlijk ten opzichte van random UUID’s, die overal in de boom terechtkomen.

Voor API‑ontwerpers die publiek‑zichtbare ID’s willen gebruiken (bijvoorbeeld https://api.example.com/users/01ARZ3NDEKTSV4RRFFQ69G5FAV) is ULID een uitstekende keuze. De ID’s zijn moeilijk te raden vanwege de 80 random bits, maar wel kort genoeg om handmatig over te typen, zonder verwarring over hoofdlettergebruik of streepjes. Omdat ze URL‑veilig zijn, hoeft een ontwikkelaar ze niet te escapen.

In gedistribueerde systemen kunnen verschillende nodes onafhankelijk ULID’s genereren zonder centrale coördinatie. De timestamp zorgt voor een globale ordening, mits de klokken gesynchroniseerd zijn. Als dat niet het geval is, kunnen ID’s van een node met een achterlopende klok later komen dan ID’s van een node met een vooruitlopende klok – maar dat is een bekend nadeel van elke time‑based identifier.

De tool zelf is bedoeld om snel een set ULID’s te krijgen voor testdoeleinden, voor het vullen van een database met voorbeeldgegevens, of voor het aanmaken van unieke sleutels in een prototype. Omdat de generatie lokaal gebeurt, is er geen wachttijd en kun je direct kopiëren.

FAQ

Vraag: Kan ik met deze tool ook ULID’s in kleine letters krijgen?
De tool toont altijd hoofdletters, maar ULID’s zijn case‑insensitive. Je kunt ze dus zonder problemen converteren naar kleine letters voordat je ze gebruikt. Het alfabet is ontworpen om hoofdletteronafhankelijk te zijn.

Vraag: Wat gebeurt er als ik meer dan 100 ID’s nodig heb?
Het invoerveld accepteert alleen waarden van 1 tot en met 100. Wil je meer ID’s, dan kun je de generatie meerdere keren herhalen. Elke nieuwe set krijgt een nieuwe timestamp, dus de ID’s van de eerste en tweede keer zijn sorteerbaar.

Vraag: Hoe betrouwbaar is de random‑generator in de browser?
De tool gebruikt crypto.getRandomValues(), een cryptografisch sterke generator die in alle moderne browsers beschikbaar is. Dit is dezelfde bron die voor versleuteling wordt gebruikt. Het is veiliger dan Math.random() die niet voor beveiliging is ontworpen.

Vraag: Kunnen twee gebruikers van deze tool dezelfde ULID krijgen?
In theorie is dat mogelijk, maar de kans is extreem klein door de 80 random bits. Zelfs als twee gebruikers exact dezelfde milliseconde gebruiken (hetgeen onwaarschijnlijk is op verschillende klokken), is de kans op een botsing verwaarloosbaar. In de praktijk wordt ULID als collision‑resistant beschouwd.

Vraag: Waarom zijn I, L, O en U uit het alfabet weggelaten?
Die letters worden vaak verward met cijfers (1, 0) of met elkaar (I en L, O en Q). Door ze weg te laten, worden typefouten bij handmatige invoer vrijwel geëlimineerd. Dit is een van de ontwerpkeuzes van Crockfords base32.

Vraag: Kan ik deze ULID’s ook gebruiken als primary key in een database die geen 26‑karakterkolommen ondersteunt?
ULID past in een CHAR(26) of VARCHAR(26). In binaire vorm (128 bits) kun je het in een BINARY(16) opslaan – dat is efficiënter. De pagina genereert echter alleen de tekstuele representatie. Je kunt die zelf omzetten naar bytes als je database dat vereist.