UUID v4 Generator
Generate cryptographically random UUID v4
…
Formatteren
UUID v4 is de meest gebruikte UUID-versie in moderne software. In tegenstelling tot zijn varianten die bits afleiden van een tijdstempel of een namespace-hash, wordt UUID v4 volledig opgebouwd uit willekeurige gegevens — wat het de eenvoudigste en meest draagbare keuze maakt wanneer u een unieke identificator nodig heeft die geen metadata over zijn oorsprong bevat.
Deze generator gebruikt crypto.randomUUID(), de native browser- en Node.js-API, die entropie onttrekt aan de cryptografisch veilige willekeurige getallengenerator van het besturingssysteem — dezelfde bron die wordt gebruikt voor TLS-sleutelmateriaal.
Wat is UUID v4?
Een Universally Unique Identifier (UUID) is een 128-bit label gestandaardiseerd in RFC 4122. Het wordt doorgaans weergegeven als 32 hexadecimale cijfers gegroepeerd door koppeltekens in het patroon 8-4-4-4-12:
In UUID v4 zijn 122 van de 128 bits willekeurig. De resterende 6 bits zijn vaste velden die door de specificatie worden vereist: 4 bits coderen de versie (0100 = 4) en 2 bits coderen de RFC 4122-variant (10). Die vaste bits verklaren waarom de derde groep altijd begint met 4 en de vierde groep altijd begint met 8, 9, a of b.
Anatomie van een UUID v4
Uitsplitsing van 550e8400-e29b-41d4-a716-446655440000:
| Segment | Bits | Betekenis |
|---|---|---|
| 550e8400 | 32 willekeurig | time_low (naam is historisch — volledig willekeurig in v4) |
| e29b | 16 willekeurig | time_mid (historische naam — volledig willekeurig in v4) |
| 41d4 | 4 vast + 12 willekeurig | Versienibble 4 (binair 0100) + 12 willekeurige bits |
| a716 | 2 vast + 14 willekeurig | Variantbits 10 (MSBs van eerste byte) + 14 willekeurige bits |
| 446655440000 | 48 willekeurig | node (volledig willekeurig in v4) |
8, 9, a of b — omdat de hoge twee bits van die byte zijn vastgesteld op 10 (de RFC 4122-variantmarkering), waardoor de resterende twee bits vrij zijn.UUID v4 vs andere versies
RFC 4122 definieert vijf UUID-versies. Elke versie lost een ander probleem op:
Combineert een 60-bit tijdstempel (100-nanoseconde intervallen sinds oktober 1582) met het MAC-adres van de host. Monotoon toenemend binnen een machine.
Use when: u tijdgeordende ID's nodig heeft en er geen bezwaar tegen heeft het serveridentiteit en generatietijd te onthullen.
Deterministisch: dezelfde namespace + naam levert altijd dezelfde UUID op. Gebruikt MD5-hashing.
Use when: u reproduceerbare ID's nodig heeft van een bekende namespace (bijv. DNS-namen). Geef de voorkeur aan v5 boven v3.
122 bits cryptografisch veilige willekeurigheid. Geen tijdstempel, geen MAC, geen namespace. De meest voorkomende algemene keuze.
Use when: u unieke ID's nodig heeft zonder structurele betekenis en maximale privacy.
Zoals v3 maar gebruikt SHA-1. Nog steeds deterministisch vanuit namespace + naam.
Use when: u reproduceerbare, op inhoud geadresseerde identificatoren nodig heeft (bijv. stabiele ID's voor resources geïdentificeerd door URL).
Nieuwer (RFC 9562, 2024). Codeert een Unix-millisecondentijdstempel in de hoge bits, dan willekeurige bits. Sorteerbaar en database-vriendelijk.
Use when: u database-index-vriendelijke ID's nodig heeft met natuurlijke tijdvolgorde (geef de voorkeur aan v7 boven v1 voor nieuwe projecten).
Wanneer UUID v4 gebruiken
UUID v4 is het juiste hulpmiddel in de overgrote meerderheid van situaties waarin u simpelweg een 'unieke ID' nodig heeft zonder aanvullende beperkingen:
Gebruikers- en account-ID's
Ondoorzichtige gebruikers-ID's die niets onthullen over het tijdstip van aanmaak van het account of de serveridentiteit. Kunnen niet worden opgesomd of geraden.
Database primaire sleutels
Werkt met elke database-engine. UUID v4 is veilig om aan de clientzijde te genereren en samen te voegen uit gedistribueerde bronnen zonder coördinatie — geen sequentietabel of centrale ID-service vereist.
Sessie- en token-ID's
122 bits willekeurigheid maakt brute-force raden rekenkundig onhaalbaar — vergelijkbaar in sterkte met een 122-bit willekeurig token.
Bestands- en objectnamen
Deduplicatieveilige bestandsnamen voor uploads, S3-objectsleutels of cache-items. Geen risico dat twee clients naar dezelfde sleutel schrijven.
Idempotentiesleutels
Genereer een UUID op de client voordat u een verzoek indient. De server kan veilig opnieuw geprobeerde verzoeken dedupliceren zonder een gedeelde teller.
Correlatie- en trace-ID's
Voeg een UUID toe aan elke logboekregel en gedistribueerde trace-span. Geen coördinatie nodig tussen services of machines.
Botsingskansbepaling
Met 122 willekeurige bits bevat de UUID v4-ruimte 2122 ≈ 5,3 × 1036 mogelijke waarden. De kans op een botsing volgt het verjaardagsparadox:
De vaak genoemde benchmark: om een 50% kans op een enkele botsing te hebben, zou u ongeveer 2,71 × 1018 UUIDs moeten genereren. Met een snelheid van 1 miljard UUIDs per seconde zou dat ongeveer 85 jaar continue generatie kosten. Voor elke praktische toepassing zijn botsingen geen praktisch probleem.
Codevoorbeelden
JavaScript — Browser en Node.js 14.17+
De methode crypto.randomUUID() is native beschikbaar in alle moderne browsers (Chrome 92+, Firefox 95+, Safari 15.4+) en in Node.js 14.17+. Geen pakketinstallatie vereist.
// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"
// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())Node.js — oudere versies (uuid-pakket)
const { v4: uuidv4 } = require('uuid')
const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"Python
import uuid # Generate a UUID v4 id = str(uuid.uuid4()) # → '110e8400-e29b-41d4-a716-446655440000' # The uuid module uses os.urandom() — cryptographically secure print(uuid.uuid4().hex) # without hyphens # → '110e8400e29b41d4a716446655440000'
Go
import "github.com/google/uuid" id := uuid.New().String() // → "110e8400-e29b-41d4-a716-446655440000" // Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic) // Always prefer github.com/google/uuid for production use
Rust
# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }use uuid::Uuid; let id = Uuid::new_v4().to_string(); // → "110e8400-e29b-41d4-a716-446655440000"
Veelgestelde vragen
Is UUID v4 cryptografisch veilig?
UUID v4 zelf is geen beveiligingsprimitief — het is een identificatorformaat. Echter, wanneer gegenereerd via crypto.randomUUID() (browser of Node.js) of gelijkwaardige OS-niveau API's, is de onderliggende entropie cryptografisch veilig. Dit betekent dat UUID v4-waarden geschikt zijn voor gebruik als sessietokens of idempotentiesleutels, waar onvoorspelbaarheid van belang is. Gebruik geen op Math.random() gebaseerde UUID-generators voor beveiligingsgevoelige contexten — gebruik alleen API's die expliciet putten uit de OS-CSPRNG.
Kunnen twee UUID v4's ooit gelijk zijn?
Theoretisch ja, maar praktisch nee. De kans op het genereren van een duplicaat binnen een realistisch dataset (miljarden ID's) is astronomisch klein — veel minder waarschijnlijk dan een hardwarefout die gegevenscorruptie veroorzaakt. UUID v4-botsingen worden in het ontwerp van productiesystemen als onmogelijk beschouwd. Als u een garantie van nul botsingen echt nodig heeft, gebruik dan een gecentraliseerde teller of een databasesequentie.
UUID v4 vs nanoid — welke moet ik gebruiken?
Beide zijn willekeurige ID-generators ondersteund door een CSPRNG. De belangrijkste verschillen:
- UUID v4 volgt de RFC 4122-standaard, wordt herkend door elke database en elk framework, en vereist geen afhankelijkheden (native
crypto.randomUUID()). - nanoid gebruikt een URL-veilig alfabet en is standaard korter (21 tekens vs 36). Nuttig wanneer URL-lengte of leesbaarheid van belang is. Vereist een npm-pakket.
Geef de voorkeur aan UUID v4 wanneer interoperabiliteit met externe systemen van belang is (API's, databases, logging-infrastructuur). Geef de voorkeur aan nanoid wanneer u kortere ID's wilt en de volledige stack beheert.
Moet ik UUID's opslaan als strings of binair in databases?
Voor de meeste databases is opslaan als een UUID- of BINARY(16)-kolom (16 bytes) efficiënter dan een VARCHAR(36)-string (36 bytes). PostgreSQL heeft een native uuid-type. MySQL en MariaDB werken goed met BINARY(16) en de UUID_TO_BIN() / BIN_TO_UUID()-hulpfuncties. SQLite-gebruikers slaan doorgaans op als TEXT. De opslagkeuze heeft geen effect op uniciteit of juistheid.
Waarom heeft UUID v4 koppeltekens — en kan ik ze weglaten?
Koppeltekens zijn onderdeel van de canonieke UUID-representatie gedefinieerd door RFC 4122. Ze zijn puur cosmetisch — ze bevatten geen informatie en beïnvloeden de 128-bit waarde niet. Ze weglaten geeft u een compacte 32-teken hexadecimale string die functioneel gelijkwaardig is. De meeste UUID-parsers accepteren beide vormen. Gebruik bij twijfel de canonieke koppeltekens-vorm voor maximale compatibiliteit met tools en databases van derden.
const id = crypto.randomUUID() // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '') // "550e8400e29b41d4a716446655440000"