UUID v4-generator

Wat deze pagina biedt

Deze pagina genereert één of meer UUID v4-identifiers – willekeurige, 36‑karakter tellende strings in het standaardformaat 8‑4‑4‑4‑12. U bepaalt het aantal (1 tot 100), of u hoofdletters gebruikt (A–F in plaats van a–f) en of de koppeltekens worden opgenomen. De ID’s verschijnen direct in uw browser; u kopieert een enkel ID door erop te klikken of kopieert alle gegenereerde ID’s in één klik. Het bijzondere aan deze specifieke tool is de combinatie van 122 bits pure willekeur per UUID (de overige 6 bits zijn vaste versie‑ en variantbits) en de transparante controle over het formaat. Doordat UUID v4‑waarden willekeurig sorteren – ze bevatten geen tijd‑ of volgorde‑informatie – fragmenteren ze B‑tree‑indexen wanneer ze als primaire sleutel in een database worden gebruikt. Dat is een essentieel verschil met tijd‑gesorteerde ID’s zoals UUID v7 of ULID. De botsingskans is voor praktische doeleinden verwaarloosbaar. De pagina stelt u in staat precies die eigenschappen te beïnvloeden die voor UUID v4 relevant zijn: hoofdlettergebruik en koppeltekens.

Structuur van UUID v4: de 122‑bits willekeur

Een UUID versie 4 volgt de specificatie RFC 4122. De canonieke notatie is een 36‑karakter string: 32 hexadecimale cijfers, gegroepeerd in vier groepen van 8‑4‑4‑4 en één van 12, gescheiden door koppeltekens. Van deze 128 bits zijn er 122 volledig willekeurig gegenereerd door de browser (via crypto.randomUUID of gelijkwaardige API’s). De overige 6 bits zijn voorgeschreven:

• 4 bits die de versie aangeven (in dit geval binair 0100, wat overeenkomt met versie 4).
• 2 bits die de variant aangeven (binair 10 voor de RFC 4122‑variant).

Het gevolg is dat elk gegenereerd UUID v4 garanties biedt over zijn format: de dertiende hexadecimale start altijd met 4 (bijv. 4‑...), en de zeventiende hexadecimale start met een van 8, 9, a of b (in kleine letters) of A, B (in hoofdletters). Deze vaste posities zijn zichtbaar in elk UUID v4 dat de pagina toont.

Wanneer u de schakelaar “koppeltekens verwijderen” inschakelt, verdwijnen de vier koppeltekens en houdt u een aaneengesloten string van 32 hexadecimale karakters over. Dat is compacter en bijvoorbeeld handig in URL’s of tokens waar koppeltekens extra codering vereisen. De onderliggende 122 bits willekeur blijven onveranderd.

Willekeurigheid en botsingskans

De hoeveelheid entropie van 122 bits is gigantisch. Het totale aantal mogelijke UUID v4‑waarden is exact 2²². Ter vergelijking: er zijn ongeveer 2⁸⁰ atomen in het waarneembare heelal. De kans dat twee willekeurig gegenereerde UUID v4‑waarden botsen is nagenoeg nul voor elk praktisch scenario. De standaard kansberekening hiervoor gebruikt de geboortedag‑paradox: wanneer u 2²²/2 = 2⁶¹ UUID’s genereert (ruim 2,3 × 10¹⁸), is de kans op een enkele botsing ongeveer 50%. In de praktijk genereert geen enkele organisatie een dergelijk aantal. Zelfs bij 10 miljard gegenereerde ID’s blijft de kans op een botsing kleiner dan 10⁻¹⁸. De tool genereert de ID’s lokaal in de browser – er wordt geen willekeur naar een server gestuurd. De random functie gebruikt zo mogelijk de best beschikbare bron (bijv. Crypto.getRandomValues), wat geschikt is voor beveiligingsgevoelige toepassingen zoals API‑tokens of sessie‑IDs.

Impact op database‑indexering

Het meest besproken nadeel van UUID v4 in databases is de willekeurige sorteerorde. Omdat de waarden geen correlatie vertonen met het tijdstip van aanmaak of enige andere natuurlijke volgorde, worden ze bij invoeging in een B‑tree‑index (de standaardindexstructuur in relationele databases zoals PostgreSQL, MySQL, SQL Server) over willekeurige posities verspreid. Dit veroorzaakt:

• Fragmentatie van de indexbladeren: elke nieuwe invoeging moet in een ander blad worden geplaatst, waardoor de index steeds opnieuw moet worden gesplitst.
• Verminderde cache‑locality: gegevens die samen zijn opgeslagen, worden zelden sequentieel gelezen.
• Langere schrijftijden vergeleken met monotoon stijgende sleutels (zoals BIGSERIAL of UUID v7).

Databases kunnen dit verzachten door het gebruik van geclusterde indexen of heap‑tabellen, maar de prestatievermindering blijft meetbaar zodra het aantal rijen in de miljoenen loopt. Voor toepassingen waar schrijfprestaties kritisch zijn – bijvoorbeeld logs of gebeurtenisstromen – is een tijd‑gesorteerde UUID v7 of ULID een betere keuze. Voor lees‑zware workloads of systemen waar de ID’s uitsluitend dienen als unieke toets in een gedistribueerd systeem zonder centraal coördinatiepunt, weegt de willekeur vaak op tegen het prestatieverlies.

Gebruiksscenario’s voor niet‑sequentiële ID’s

Waarom zou iemand bewust kiezen voor een ID dat willekeurig sorteert, ondanks de indexeringnadelen? Enkele scenario’s:

• Veiligheid en onvoorspelbaarheid: wanneer u niet wilt dat gebruikers het volgende ID raden (bijv. gebruiker/1234 versus gebruiker/a8f3-c71e), voorkomt willekeurige ID’s enumeratieaanvallen.
• Gedistribueerde systemen: zonder centrale database is het coördineren van een autonome volgorde onmogelijk. UUID v4 kan overal worden gegenereerd zonder overleg.
• Offline‑toepassingen: een client kan ID’s aanmaken zonder eerst te moeten synchroniseren met een server.
• Testen en gegevensgeneratie: voor het vullen van testdatabases met realistische, unieke sleutels is willekeur efficiënt.
• API‑sleutels en tokens: de hoge entropie maakt ze onvoorspelbaar; de lengte is goed afgestemd op de balans tussen leesbaarheid en veiligheid.

Als ontwikkelaar kunt u op deze pagina snel een batch van bijvoorbeeld 100 UUID’s genereren om te prototypen of een database te vullen. De toggles voor hoofdletters en koppeltekens zijn direct van toepassing op uw volgende stap: kopiëren en plakken in code, configuratie of SQL‑statement.

Aanpassingsopties: wanneer gebruik je hoofdletters en koppeltekens?

Hoofdletters (Uppercase)
Als u de schakelaar inschakelt, worden de hexadecimale cijfers a–f weergegeven als A–F. Dit heeft geen invloed op de uniciteit: kleine letters en hoofdletters worden op dezelfde manier geïnterpreteerd in de meeste systemen. Toch zijn er redenen om hoofdletters te gebruiken:

• Leesbaarheid: sommige mensen vinden A–F beter onderscheidbaar van de cijfers 0–9 dan a–f.
• Interoperabiliteit: bepaalde bibliotheken of systemen (zoal Windows registry) gebruiken standaard hoofdletters.
• Consistentie in logging: als uw systeem overal hoofdletters gebruikt, kunt u hier hetzelfde formaat kiezen.

Koppeltekens verwijderen
Het weglaten van de koppeltekens verkort de string van 36 naar 32 karakters. Dit is handig:

• In URL’s, headers of tokens waar koppeltekens ontsnapt moeten worden (bijv. in API‑paden).
• In databasekolommen die stringvergelijking moeten doen: zonder koppeltekens is de string korter en vaak iets sneller te vergelijken.
• Wanneer u de ID’s in een context plaatst waar het 32‑karakterformaat al gebruikelijk is (bijv. MongoDB’s ObjectId is 24 hex karakters).

Let op: het verwijderen van koppeltekens verandert de onderliggende willekeur niet. U kunt de onbewerkte 32‑hex string later altijd weer toevoegen van koppeltekens op de vaste posities (8‑4‑4‑12), maar let op dat de vaste posities van versie en variant dan mogelijk niet meer zichtbaar zijn. De tool voorziet niet in het omgekeerde proces.

Veelgestelde vragen (FAQ)

1. Hoe groot is de kans dat twee UUID v4’s botsen?
De kans op een botsing bij N gegenereerde UUID’s is ongeveer N² / (2 * 2¹²²). Voor N = 1 miljard is die kans ~ 10⁻¹⁸. U kunt miljarden genereren zonder praktische kans op een botsing.

2. Waarom raden sommige databases aan UUID v4 niet als primaire sleutel te gebruiken?
Omdat de willekeurige ordening leidt tot indexfragmentatie, wat schrijfprestaties verlaagt. Als uw database vele miljoenen rijen heeft en schrijfintensief is, overweeg dan UUID v7 (tijd‑gesorteerd) of een andere monotone sleutel.

3. Kan ik de gegenereerde ID’s gebruiken voor beveiligingstokens?
Ja, mits u de gegenereerde ID’s vertrouwt. De browser gebruikt crypto.randomUUID of getRandomValues, die cryptografisch sterke willekeur bieden. De 122 bits entropie zijn voldoende voor API-tokens, sessie‑IDs en CSRF‑tokens. Houd er wel rekening mee dat de ID’s op deze pagina alleen lokaal worden gegenereerd en niet worden opgeslagen.

4. Wat is het verschil tussen UUID v4 en UUID v7?
UUID v7 bevat een milicentimetertijdstempel in de eerste 48 bits, wat zorgt voor monotone sorteerbaarheid. Hierdoor heeft UUID v7 minder indexfragmentatie. UUID v4 is volledig willekeurig en biedt geen temporele ordening. De keuze hangt af van uw prioriteit: sorteerbaarheid of maximale onvoorspelbaarheid.

5. Hoe beïnvloeden de toggles (hoofdletters, koppeltekens) de uniciteit?
Ze veranderen niets aan de onderliggende willekeur. Hoofdletters en kleine letters zijn alleen een kwestie van weergave. Koppeltekens zijn separators die u kunt verwijderen zonder informatieverlies. Het enige verschil is de stringlengte en leesbaarheid.

6. Kan ik 1000 UUID’s in één keer genereren?
Nee, het maximum is 100. Dit is een opzettelijke grens: voor meer dan 100 ID’s kunt u de tool meerdere keren gebruiken of een script schrijven dat dezelfde lokale methode aanroept. Het direct knippen van een lange lijst in een browser kan de gebruiker overweldigen; 100 is een praktische bovengrens voor handmatig gebruik.

---

Alle ID‑generatie vindt plaats in uw browser. Er worden geen gegevens naar een server verzonden. De pagina past de getoonde ID’s onmiddellijk aan bij elke wijziging van instellingen.