De UUID-tools van ToolDeck dekken alle belangrijke unieke identifier-formaten op één plek. De collectie omvat: UUID v4 Generator voor willekeurige cryptografisch sterke IDs; UUID v7 Generator voor op timestamp sorteerbare primaire sleutels; UUID v1 Generator voor op tijd en MAC-adres gebaseerde identifiers; UUID v2 Generator voor verouderde DCE-systemen; UUID v3 Generator voor deterministische op MD5 gebaseerde IDs; ULID Generator voor compacte sorteerbare strings; NanoID Generator voor korte URL-veilige tokens; CUID Generator voor het originele collision-resistente formaat; CUID2 Generator voor de moderne opvolger; en UUID Decoder voor het inspecteren van bestaande identifiers. Alle tools draaien volledig in je browser via de Web Crypto API — er worden geen gegevens naar een server verzonden, geen account vereist.
Wat zijn UUID- en unieke ID-tools?
Een UUID (Universally Unique Identifier) is een 128-bits identifier gestandaardiseerd in RFC 9562 (voorheen RFC 4122). Geschreven als 32 hexadecimale tekens in het formaat 8-4-4-4-12, ziet een UUID er zo uit: 550e8400-e29b-41d4-a716-446655440000. De standaard definieert meerdere versies, elk met een andere strategie om uniciteit te garanderen: willekeurige getallen, tijdstempels of deterministisch hashen.
UUIDs zijn ontworpen zodat gedistribueerde systemen identifiers kunnen genereren zonder een centrale coördinator. Of je nu een primaire sleutel toewijst in PostgreSQL, een sessietoken genereert in een webapplicatie, of een bestand benoemt in objectopslag — UUIDs stellen elk knooppunt in je systeem in staat om zelfstandig een globaal unieke ID te maken, met een kans op botsingen die in de praktijk verwaarloosbaar klein is.
Naast de UUID-standaard zijn er alternatieve unieke ID-formaten ontstaan om specifieke beperkingen te verhelpen: ULID en UUID v7 voegen lexicografische sorteerbaarheid toe voor efficiënte database-indexen; NanoID verkleint de omvang voor URLs en cookies; CUID2 geeft prioriteit aan fingerprint-gebaseerde collision-resistentie voor client-side generatie bij hoog volume.
Waarom UUID-tools op ToolDeck gebruiken?
De UUID-tools van ToolDeck draaien volledig in je browser. Geen API-aanroepen, geen server-side verwerking, geen geregistreerde gegevens. Elke generator gebruikt de Web Crypto API (crypto.getRandomValues) voor cryptografisch sterke entropie — dezelfde bron die browsers gebruiken voor TLS-sleutelmateriaal.
🔐Cryptografisch sterke entropie
Alle op willekeur gebaseerde generators (UUID v4, NanoID, CUID2) gebruiken crypto.getRandomValues, niet Math.random. De uitvoer is geschikt voor beveiligingsgevoelige toepassingen zoals sessietokens en API-sleutels.
📦Alle belangrijke ID-formaten op één plek
UUID v1 tot en met v7, ULID, NanoID, CUID en CUID2 — alle formaten die een ontwikkelaar nodig heeft, met opties voor bulkgeneratie en kopiëren met één klik.
🔍Bestaande IDs decoderen en inspecteren
De UUID Decoder extraheert de versie, variant, tijdstempel en knooppuntvelden uit elke UUID. Nuttig voor debuggen, auditing en het begrijpen van verouderde IDs in je codebase.
⚡Geen setup, werkt offline
Geen installatie, geen aanmelding, geen runtime-afhankelijkheden. Open de pagina en genereer. Alle tools werken offline zodra de pagina is geladen — nuttig in air-gapped omgevingen of beperkte netwerken.
Toepassingen van de UUID-tools
Unieke identifiers komen voor op elke laag van de stack. Zo gebruiken verschillende rollen UUID-generatietools:
Database primaire sleutels
Backend-engineers kennen UUID v4 of UUID v7 toe als primaire sleutels in PostgreSQL, MySQL en MongoDB. Het tijdstempelprefix van UUID v7 houdt rijen fysiek geordend op schijf, waardoor pagina-splitsingen worden voorkomen bij schrijfintensieve workloads.
Frontend-status en component-IDs
Frontend-ontwikkelaars gebruiken NanoID of UUID v4 om stabiele React-keys te genereren voor dynamisch aangemaakte lijstitems, dialoog-IDs voor ARIA-toegankelijkheidsattributen en idempotentietokens voor formulierinzendingen.
Gedistribueerde event-streams
In event-driven systemen heeft elk event een globaal unieke, sorteerbare ID nodig. DevOps- en platform-engineers gebruiken ULID of UUID v7 zodat Kafka-consumers, logaggregators en audit-trails gesorteerd kunnen worden op aanmaaktijd zonder een secundair tijdstempelveld.
Testdata genereren
QA-engineers genereren UUID-batches in bulk om testdatabases te vullen met realistische, niet-sequentiële IDs. Deterministisch UUID v3 of v5 laat hen dezelfde ID regenereren vanuit een bekende invoer — nuttig voor reproduceerbare testfixtures.
Microservice correlatie-IDs
Het koppelen van een UUID aan elk binnenkomend HTTP-verzoek en dit doorgeven via service-aanroepen (X-Request-ID header) stelt gedistribueerde tracing-systemen in staat logs over services heen te correleren. UUID v4 is de de-facto standaard voor verzoek-correlatie.
Asset- en resourcenaamgeving
Sleutels voor objectopslag (S3, GCS, Cloudflare R2) en bestandsnamen van CDN-assets bevatten vaak een UUID om cache-botsingen en URL-raden te voorkomen. Het compacte 21-tekens formaat van NanoID verkort de URL vergeleken met volledige 36-tekens UUIDs.
UUID-versie- en formatreferentie
De onderstaande tabel vergelijkt alle UUID-versies met de meest gebruikte UUID-alternatieven. Gebruik hem om snel te identificeren welk formaat bij je vereisten past.
| Identifier | Algoritme | Sorteerbaar | Deterministisch | Ideaal voor |
|---|
| UUID v4 | Willekeurig (CSPRNG) | — | — | Algemene IDs, sessietokens, primaire sleutels |
| UUID v7 | Unix ms-tijdstempel + willekeurig | ✓ | — | Sorteerbare primaire sleutels, gedistribueerde event-IDs (RFC 9562) |
| UUID v1 | Tijdstempel + MAC-adres | ✓ | — | Op tijd geordende IDs, systemen met één knooppunt, verouderde compatibiliteit |
| UUID v3 | Namespace + naam + MD5 | — | ✓ | Reproduceerbare IDs vanuit bekende invoer (DNS, URLs) |
| UUID v5 | Namespace + naam + SHA-1 | — | ✓ | Zelfde als v3 met sterkere hash; prefereer v5 boven v3 |
| UUID v2 | Tijdstempel + DCE UID/GID | ✓ | — | Verouderde POSIX/DCE-omgevingen; vermijd voor nieuwe projecten |
| ULID | Tijdstempelprefix + willekeurig | ✓ | — | Sorteerbare IDs, URL-veilig, geen koppeltekens (26 tekens) |
| NanoID | Willekeurig (CSPRNG), URL-veilig alfabet | — | — | Korte IDs voor URLs, cookies, HTML-attributen (21 tekens) |
| CUID2 | Fingerprint + tijdstempel + willekeurig | — | — | Client-side generatie bij hoog volume, collision-resistent |
UUID v3 en v5 zijn deterministisch: dezelfde namespace + naam levert altijd dezelfde UUID op. Alle andere formaten genereren bij elke aanroep een nieuwe waarde.
De juiste UUID-tool kiezen
De juiste identifier hangt af van je vereisten voor sorteerbaarheid, grootte en determinisme. Gebruik deze beslissingsgids:
- 1
Als je een algemene unieke ID nodig hebt zonder speciale vereisten → UUID v4 Generator - 2
Als je IDs nodig hebt die chronologisch sorteren en compatibel zijn met de UUID-standaard → UUID v7 Generator - 3
Als je op tijd geordende IDs nodig hebt met een ingebedde tijdstempel voor systemen met één knooppunt of lage gelijktijdigheid → UUID v1 Generator - 4
Als je sorteerbare IDs nodig hebt die URL-veilig en vrij van koppeltekens zijn → ULID Generator - 5
Als je compacte, URL-veilige IDs nodig hebt die korter zijn dan een volledige UUID → NanoID Generator - 6
Als je veel IDs client-side genereert en sterke collision-resistentie nodig hebt → CUID2 Generator - 7
Als je het CUID v1-formaat nodig hebt voor compatibiliteit met bestaande systemen op basis van de originele specificatie → CUID Generator - 8
Als je dezelfde ID deterministisch moet reproduceren vanuit een namespace en naam → UUID v3 Generator - 9
Als je werkt met verouderde DCE- of POSIX-systemen die v2-identifiers vereisen → UUID v2 Generator - 10
Als je een bestaande UUID hebt en de versie, variant of tijdstempel wilt inspecteren → UUID Decoder
Zowel UUID v7 als ULID bieden tijdstempelprefix met millisecondennauwkeurigheid en lexicografische sorteerbaarheid. Het belangrijkste verschil: UUID v7 gebruikt het standaard UUID-formaat (8-4-4-4-12, 36 tekens) voor maximale ecosysteemcompatibiliteit, terwijl ULID een eigen Base32-codering gebruikt (26 tekens, URL-veilig, geen koppeltekens). Als je database, ORM of framework native UUID-kolommen ondersteunt, geef dan de voorkeur aan UUID v7. Als je kortere IDs nodig hebt zonder frameworkbeperkingen, is ULID compacter.
Veelgestelde vragen
Wat is een UUID?
Een UUID (Universally Unique Identifier) is een 128-bits waarde gestandaardiseerd in RFC 9562. Hij wordt geschreven als 32 hexadecimale cijfers in vijf door koppeltekens gescheiden groepen: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. De standaard definieert meerdere versies met verschillende uniciteitsstrategieën — willekeurig (v4), op tijdstempel gebaseerd (v1, v7), of deterministisch op naam gebaseerd (v3, v5).
Wat is het verschil tussen UUID v4 en UUID v7?
UUID v4 vult alle 122 niet-vaste bits met willekeurige data uit een cryptografisch veilige bron. UUID v7 codeert een 48-bits Unix-millisecondentijdstempel in de eerste 48 bits, gevolgd door willekeurige bits. Het resultaat: UUID v7-waarden sorteren chronologisch als gewone strings, waardoor database B-tree-indexen geordend blijven bij invoeging. UUID v7 werd toegevoegd in RFC 9562 (april 2024) en is de voorkeursoptie voor nieuwe database primaire sleutels.
Zijn UUID v4-waarden cryptografisch veilig?
UUID v4-waarden worden gegenereerd met een cryptografisch veilige pseudo-willekeurige nummergenerator (CSPRNG). Ze zijn geschikt als niet-raadbare tokens — sessie-IDs, wachtwoordherstellinks en dergelijke. Een UUID is echter op zichzelf geen geheim: het heeft geen HMAC, geen vervaldatum en geen binding aan een specifieke gebruiker. Behandel UUIDs als opaque identifiers, niet als authenticatiegegevens.
Kunnen twee verschillende systemen dezelfde UUID genereren?
De kans op een botsing voor UUID v4 is ongeveer 1 op 2^122 per paar. Om 50% kans te hebben op enige botsing zou je ongeveer 2,7 × 10^18 UUIDs moeten genereren — ver buiten wat een echt systeem produceert. UUID v1 en v7 bevatten bovendien een tijdstempel en/of willekeurige bits, waardoor accidentele botsingen nog onwaarschijnlijker worden. Voor alle praktische doeleinden zullen UUIDs van afzonderlijke systemen niet botsen.
Waarom zijn UUIDs 36 tekens lang?
Een UUID is 128 bits = 16 bytes. Gecodeerd als hexadecimaal zijn dat 32 tekens. Het UUID-formaat voegt 4 koppeltekens toe op vaste posities (na groepen van 8, 4, 4 en 4 hexadecimale cijfers) om de leesbaarheid te verbeteren en de versie- en variantbits visueel gemakkelijk te herkennen, wat totaal 36 tekens oplevert. De koppeltekens dragen geen gegevens.
Wat is ULID en hoe verschilt het van UUID?
ULID (Universally Unique Lexicographically Sortable Identifier) is een 128-bits identifier gecodeerd in Crockford Base32 (26 tekens, hoofdletterongevoelig, geen koppeltekens). De eerste 48 bits coderen de Unix-tijd in milliseconden; de resterende 80 bits zijn willekeurig. ULIDs sorteren correct als gewone strings en zijn compacter dan UUIDs. Ze maken geen deel uit van de UUID RFC — ze gebruiken een andere codering en missen de versie-/variantvelden van UUIDs.
Moet ik UUIDs of auto-increment integers gebruiken als primaire sleutels?
Auto-increment integers zijn sequentieel, compact en indexvriendelijk, maar vereisen een centrale coördinator (de database) voor toewijzing — wat mislukt in gedistribueerde systemen en rij-aantallen onthult. UUIDs (met name v7 of ULID) kunnen client-side worden gegenereerd zonder een database-round-trip, wat optimistische invoeging en gedistribueerd schrijven mogelijk maakt. De afweging is opslag (16 bytes vs. 4–8 bytes) en iets lagere indexlokaliteit voor willekeurige UUIDs (v4). UUID v7 en ULID elimineren het indexlokaliteitsprobleem door tijdstempelprefix te gebruiken.
Wat is het verschil tussen UUID v3 en UUID v5?
Zowel UUID v3 als v5 zijn deterministisch: ze produceren altijd dezelfde UUID voor hetzelfde namespace + naam-paar, waardoor ze nuttig zijn voor het genereren van reproduceerbare IDs voor DNS-vermeldingen, URLs of objectidentifiers. Het enige verschil is het hash-algoritme: v3 gebruikt MD5 (128 bits, verouderd), v5 gebruikt SHA-1 (160 bits, afgekapt tot 128 bits). Geef de voorkeur aan UUID v5 voor nieuwe projecten — SHA-1 is sterker dan MD5, ook al wordt geen van beide versies gebruikt als cryptografische hash.