Heb je een identifier nodig die niet zal botsen met eentje die door iemand anders is gemaakt, op een machine waar je nog nooit van hebt gehoord, zonder iemand om toestemming te vragen? Dat is de taak die een UUID uitvoert. Het is een 128-bits getal, geschreven als 36 tekens in het bekende 8-4-4-4-12 patroon, en het hele ontwerp is erop gericht dat twee ervan nooit hetzelfde zullen zijn, ook al is er niets dat coördineert wie welke krijgt. Deze gratis generator maakt ze in je browser: kies een versie in Versie, geef aan hoeveel je er nodig hebt in Aantal, en druk op Genereren. De pagina opent met een enkele v4, de versie die de meeste projecten willen, dus een eerste identifier is slechts één klik verwijderd.
Elke identifier wordt door je browser gebouwd via de Web Crypto API. Versie 4 gebruikt crypto.randomUUID() waar de browser dit aanbiedt en anders crypto.getRandomValues() — een cryptografisch sterke bron van willekeur in plaats van een JavaScript pseudo-willekeurige functie zoals Math.random(). Versie 7 plaatst een 48-bits milliseconde timestamp vooraan, vervolgens een 12-bits teller die oploopt binnen dezelfde milliseconde, en dan 62 willekeurige bits, wat de sorteermethode is die wordt beschreven in RFC 9562; die teller is de reden waarom een batch van duizend op volgorde wordt gegenereerd in plaats van door elkaar. Versie 1 combineert een timestamp met een willekeurige node-identifier waarvan de multicast-bit is ingesteld, dus het bevat nooit het adres van je netwerkkaart, zoals de originele implementaties uit de jaren 90 dat deden. Versies 3 en 5 zijn helemaal niet willekeurig: ze hashen een namespace samen met een naam, respectievelijk met MD5 en SHA-1, en ook dat hashen gebeurt op je apparaat. Er wordt niets naar een server gestuurd, er wordt niets gelogd, en als de pagina eenmaal is geladen, blijft deze werken, zelfs als de verbinding is verbroken.
Versie is het veld dat al het andere bepaalt. Versie 4 is 122 willekeurige bits zonder enige structuur — de standaard en het juiste antwoord wanneer een identifier alleen maar uniek hoeft te zijn. Versie 7 behoudt 62 willekeurige bits, maar begint met de tijd waarop het is gemaakt, zodat een set ervan gesorteerd kan worden in de volgorde waarin ze zijn gemaakt; dit maakt het de versie om te kiezen wanneer de identifier een databasesleutel wordt. Versie 1 is het originele op tijd gebaseerde schema, hier bewaard voor systemen die er nog steeds om vragen. Versies 3 en 5 zijn het vreemde paar: ze zijn deterministisch, wat betekent dat dezelfde invoer altijd dezelfde identifier produceert, en ze vereisen twee extra velden — Namespace, wat een van de standaardruimtes DNS, URL, OID en X.500 is of een eigen Aangepaste namespace, en Naam, de string die wordt geïdentificeerd. Geef v5 de URL-namespace en https://example.com/a en je krijgt vandaag, morgen en op de machine van iemand anders exact dezelfde UUID. Om die reden verdwijnt Aantal wanneer v3 of v5 is geselecteerd: duizend kopieën van een deterministische waarde zouden slechts duizend kopieën van één deterministische waarde zijn. Voor elke andere versie loopt Aantal van 1 tot 1000.
Vier schakelaars veranderen de vorm van de uitvoer zonder de onderliggende 128 bits te wijzigen. Hoofdletters drukt de hexadecimale cijfers in kapitalen af, Zonder streepjes geeft de compacte vorm van 32 tekens waaraan sommige kolommen en bestandsnamen de voorkeur geven, en Accolades wikkelt de waarde in { } — de vorm die Windows en de .NET-wereld een GUID noemen. Onder Geavanceerde opties voegt urn:uuid: de prefix toe die het een formele URN maakt; het schakelt Accolades en Zonder streepjes uit zolang het aan staat, omdat de standaard precies één URN-vorm toestaat en dat is de canonieke vorm met streepjes. Kopieerformaat bepaalt hoe een batch wordt samengevoegd wanneer je deze meeneemt: één per regel, gescheiden door komma's, of elke waarde tussen aanhalingstekens met een komma erachter, die je direct in een array in de code kunt plakken. Onder het resultaat staat een regel die de willekeur in bits rapporteert — 122 voor v4, 62 voor v7 — en, voor v7, de timestamp die is gecodeerd in de eerste identifier van de batch, zodat de tijd binnen de waarde zichtbaar is in plaats van geïmpliceerd. Alles kopiëren en Opslaan als bestand respecteren beide Kopieerformaat. Geschiedenis bewaart je laatste 10 batches in je eigen browser: klik op een om deze terug te halen, kopieer of verwijder een enkele invoer, of wis alles. Wissen leegt het resultaat en laat je instellingen met rust, en voorbij 50 identifiers wordt de lijst één scrollbaar blok in plaats van vijftig rijen.
Het meest consequente op deze pagina is het verschil tussen v4 en v7 als primaire sleutel, en dat is geen kwestie van smaak. Database-indexen zijn bomen die in gesorteerde volgorde worden gehouden, en waar een nieuwe sleutel in die volgorde belandt, bepaalt hoeveel werk het invoegen kost. Een v4-sleutel is willekeurig, dus opeenvolgende invoegingen belanden in ongerelateerde hoeken van de index: pagina's die vol waren worden opgesplitst, de delen van de boom die de database in het geheugen houdt, zijn zelden de delen die de volgende invoeging nodig heeft, en de index eindigt groter en meer gefragmenteerd dan de rijen waarnaar het wijst rechtvaardigen. Een v7-sleutel begint met de huidige milliseconde, dus opeenvolgende invoegingen belanden naast elkaar aan de rechterkant van de boom, wat het patroon is dat een auto-incrementerende integer produceert en het patroon waar indexstructuren omheen zijn gebouwd. Dat is de hele afweging: v7 biedt je het invoeggedrag van een sequentiële sleutel met behoud van de eigenschap waarom je in de eerste plaats voor UUID's hebt gekozen, namelijk dat iedereen er een kan smeden zonder een server te vragen. Wat het kost is dat de aanmaaktijd nu leesbaar is in de identifier, en of dat ertoe doet is een vraag over je data, niet over het formaat.
Niets controleert ooit of een UUID uniek is; de grootte is de garantie. Er is geen register, geen retourreis naar een server, geen lookup — een generator produceert een nummer en overhandigt het, en de reden dat twee ervan niet botsen is simpelweg dat er 2^122 mogelijke v4-waarden zijn, ongeveer 5,3 sextiljoen. Het birthday problem is de eerlijke manier om dat in te schatten: je zou ongeveer 2,7 triljoen identifiers nodig hebben voordat er een evenredige kans is dat twee ervan overeenkomen, wat neerkomt op een miljard nieuwe UUID's elke seconde gedurende 86 jaar. Het is de moeite waard om precies te zijn over wat dat wel en niet belooft. Het is een statistische garantie, geen rekenkundige, en deze geldt alleen zolang de willekeur eronder echt is — een generator met een slechte seed, of een virtuele machine die samen met zijn entropiepool is gekloond, verbreekt dit op een manier die het formaat niet kan detecteren. Versie 7 vernauwt de vraag nog verder: binnen één milliseconde kan één generator zichzelf helemaal niet herhalen, omdat de teller oploopt in plaats van dobbelstenen te gooien, en over onafhankelijke generatoren doen de 62 willekeurige bits het werk.
Een UUID is een identifier, geen wachtwoord. Versie 4 is onvoorspelbaar, en dat verleidt mensen ertoe het als een geheim te behandelen — een wachtwoord-reset link, een onraadbare URL, een sessietoken, een API-sleutel. De onvoorspelbaarheid is echt, maar geheimhouding is een eigenschap van hoe er met een waarde wordt omgegaan, en identifiers worden door hun ontwerp slordig behandeld: ze zitten in URL's, die in de browsergeschiedenis, serverlogs, referer-headers en analyses belanden, en ze worden in chatberichten geplakt. De andere versies zijn nog slechtere kandidaten. Zowel versie 1 als versie 7 coderen het moment van aanmaken, dus iedereen die er een in handen heeft weet ongeveer wanneer deze is gemaakt en kan de omgeving beperken van alles wat tegelijkertijd is gemaakt. Versies 3 en 5 zijn expres deterministisch: een v5 UUID van een e-mailadres is geen gehasht geheim, het is een waarde die iedereen met hetzelfde adres in een seconde kan berekenen. Gebruik een UUID om iets een naam te geven. Gebruik een wachtwoordgenerator of een token uit een bibliotheek die is gebouwd voor geheimen, wanneer de waarde onbekend moet blijven.
Waarom kiezen voor deze UUID-generator?
- Uitsluitend generatie in de browser: identifiers worden op je apparaat gemaakt en nooit ergens heen gestuurd
- Willekeur via Web Crypto API: cryptografisch veilig, niet Math.random()
- Vijf versies op één plek: v1, v3, v4, v5 en v7, zonder van tool te hoeven wisselen
- Oprecht gesorteerde v7: een teller binnen de milliseconde, zoals beschreven in RFC 9562
- Deterministische v3 en v5 met de vier standaard namespaces of een eigen namespace
- Tot 1000 tegelijk, met een compacte scrollbare lijst voorbij de vijftig
- Elke gangbare vorm: met streepjes, kaal, in hoofdletters, tussen accolades of als urn:uuid: URN
- Kopiëren als regels, komma's of geciteerde waarden die je rechtstreeks in de code plakt
- Onbeperkt en gratis: geen aanmelding, geen gebruikslimieten, niets op onze servers
UUID's duiken overal op waar iets een naam moet krijgen voordat er bevestigd kan worden dat de naam vrij is. Applicatiecode genereert ze voor rijen die op het punt staan te worden ingevoegd, zodat het object een identiteit heeft voordat het ooit de database heeft bereikt en een client ernaar kan verwijzen terwijl de schrijfactie nog gaande is. Gedistribueerde systemen leunen nog zwaarder op ze: meerdere diensten die in één tabel schrijven, een offline mobiele client die offline records aanmaakt in een vliegtuig, een wachtrij die het bericht moet herkennen dat het al heeft verwerkt — geen van deze kan zijn beurt afwachten bij een gedeelde teller. Versie 5 dekt een andere behoefte, namelijk een stabiele identifier afgeleid van iets dat je al hebt: hetzelfde document, dezelfde URL of hetzelfde account verwijst altijd naar dezelfde UUID, zodat een import twee keer kan worden uitgevoerd zonder iets te dupliceren. Elders zijn ze simpelweg het formaat dat een systeem eist — een correlatie-identifier door logs en traces heen, een bestandsnaam die niet botst wanneer uploads van duizend gebruikers in één bucket belanden, een Windows-registersleutel, een testfixture die op echte data moet lijken.
Een paar eerlijke limieten zijn het waard om te kennen. Eén batch is één versie: de waarde in Versie is van toepassing op alles erin, dus een reeks v4's en een reeks v7's zijn twee batches. Dit is een generator, geen inspecteur — een UUID erin plakken om de versie of de timestamp terug te lezen, is niet iets dat deze pagina doet. Opslaan als bestand schrijft een tekstbestand in plaats van CSV of JSON. Versie 7 onthult openlijk wanneer het is gemaakt, tot op de milliseconde, wat een echte afweging is in plaats van een fout, en versie 1 lekt op dezelfde manier tijd; als dat een probleem is voor je data, is versie 4 de versie die niemand iets vertelt. Twee speciale waarden uit de standaard zijn geen versies en zijn dus geen opties in Versie, maar je kunt ze hier vandaan kopiëren: de nil UUID, 00000000-0000-0000-0000-000000000000, en de max UUID, ffffffff-ffff-ffff-ffff-ffffffffffff. Alles op deze pagina volgt RFC 9562, de specificatie die RFC 4122 verving in 2024, dus de output wordt geaccepteerd door elke bibliotheek, database of API die überhaupt met UUID's omgaat. Binnen deze limieten is de garantie sterk: elke identifier is volgens de standaard gebouwd, vanuit cryptografisch veilige willekeur, op je eigen machine, en niemand anders ziet hem ooit.