UUID v4 Generator
Generate cryptographically random UUID v4
…
Formatera
UUID v4 är den mest använda UUID-versionen i modern mjukvara. Till skillnad från sina syskon som härleder bitar från en tidsstämpel eller en namnhash, är UUID v4 helt byggd på slumpmässiga data — vilket gör det till det enklaste och mest portabla valet när du behöver en unik identifierare utan metadata om ursprunget.
Den här generatorn använder crypto.randomUUID(), det inbyggda webbläsar- och Node.js-API:et, som hämtar entropi från operativsystemets kryptografiskt säkra slumptalsalgoritm — samma källa som används för TLS-nyckelmaterial.
Vad är UUID v4?
En Universally Unique Identifier (UUID) är en 128-bitars etikett standardiserad i RFC 4122. Den representeras vanligtvis som 32 hexadecimala siffror grupperade med bindestreck i mönstret 8-4-4-4-12:
I UUID v4 är 122 av 128 bitarna slumpmässiga. De återstående 6 bitarna är fasta fält som specificationen kräver: 4 bitar kodar versionen (0100 = 4) och 2 bitar kodar RFC 4122-varianten (10). Dessa fasta bitar är anledningen till att den tredje gruppen alltid börjar med 4 och den fjärde gruppen alltid börjar med 8, 9, a eller b.
En UUID v4:s uppbyggnad
Uppdelning av 550e8400-e29b-41d4-a716-446655440000:
| Segment | Bitar | Betydelse |
|---|---|---|
| 550e8400 | 32 slumpmässiga | time_low (historiskt namn — helt slumpmässigt i v4) |
| e29b | 16 slumpmässiga | time_mid (historiskt namn — helt slumpmässigt i v4) |
| 41d4 | 4 fasta + 12 slumpmässiga | Versionsnibble 4 (binärt 0100) + 12 slumpmässiga bitar |
| a716 | 2 fasta + 14 slumpmässiga | Variantbitar 10 (MSB av första byte) + 14 slumpmässiga bitar |
| 446655440000 | 48 slumpmässiga | node (helt slumpmässigt i v4) |
8, 9, a eller b — eftersom de två höga bitarna av den byten är fasta till 10 (RFC 4122-variantmarkören), vilket lämnar de återstående två bitarna fria att variera.UUID v4 vs andra versioner
RFC 4122 definierar fem UUID-versioner. Var och en löser ett annat problem:
Kombinerar en 60-bitars tidsstämpel (100-nanosekundintervall sedan okt 1582) med värdens MAC-adress. Monotont ökande inom en maskin.
Use when: du behöver tidsordnade ID:n och inte har något emot att läcka serveridentitet och genereringstid.
Deterministisk: samma namnrymd + namn ger alltid samma UUID. Använder MD5-hashning.
Use when: du behöver reproducerbara ID:n från ett känt namnområde (t.ex. DNS-namn). Föredra v5 framför v3.
122 bitar kryptografiskt säker slumpmässighet. Ingen tidsstämpel, ingen MAC, inget namnområde. Det vanligaste allmänna valet.
Use when: du behöver unika ID:n utan strukturell mening och maximal integritet.
Som v3 men använder SHA-1. Fortfarande deterministisk från namnrymd + namn.
Use when: du behöver reproducerbara, innehållsadresserade identifierare (t.ex. stabila ID:n för resurser identifierade av URL).
Nyare (RFC 9562, 2024). Kodar en Unix-millisekundtidsstämpel i de höga bitarna, sedan slumpmässiga bitar. Sorterbar och databasvänlig.
Use when: du behöver databasindexvänliga ID:n med naturlig tidsordning (föredra framför v1 för nya projekt).
När ska man använda UUID v4
UUID v4 är rätt verktyg i de allra flesta situationer där du helt enkelt behöver 'ett unikt ID' utan ytterligare begränsningar:
Användar- och konto-ID:n
Ogenomskinliga användar-ID:n som inte avslöjar något om kontoskapandetid eller serveridentitet. Kan inte räknas upp eller gissas.
Primärnycklar i databaser
Fungerar med alla databasmotorer. UUID v4 är säkert att generera på klientsidan och slå samman från distribuerade källor utan koordination — ingen sekvenstabell eller central ID-tjänst krävs.
Sessions- och token-ID:n
122 bitar slumpmässighet gör brute-force-gissning beräkningsmässigt omöjlig — jämförbar i styrka med en 122-bitars slumpmässig token.
Fil- och objektnamn
Deduplication-säkra filnamn för uppladdningar, S3-objektnycklar eller cacheposter. Ingen risk att två klienter skriver till samma nyckel.
Idempotensnycklar
Generera ett UUID på klienten innan du skickar en begäran. Servern kan säkert deduplicera återförsöksförfrågningar utan en delad räknare.
Korrelations- och spårnings-ID:n
Bifoga ett UUID till varje loggrad och distribuerad spårningsperiod. Ingen koordination behövs mellan tjänster eller maskiner.
Kollisionssannolikhet
Med 122 slumpmässiga bitar innehåller UUID v4-utrymmet 2122 ≈ 5,3 × 1036 möjliga värden. Sannolikheten för en kollision följer födelsedagsproblemet:
Det vanligt citerade riktmärket: för att ha 50% chans för en enda kollision skulle du behöva generera ungefär 2,71 × 1018 UUID:n. Med en hastighet av 1 miljard UUID:n per sekund skulle det ta ungefär 85 år av kontinuerlig generering. För alla verkliga applikationer är kollisioner inte ett praktiskt problem.
Kodexempel
JavaScript — Webbläsare och Node.js 14.17+
Metoden crypto.randomUUID() är tillgänglig inbyggt i alla moderna webbläsare (Chrome 92+, Firefox 95+, Safari 15.4+) och i Node.js 14.17+. Ingen paketinstallation krävs.
// 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 — äldre versioner (uuid-paketet)
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"
Vanliga frågor
Är UUID v4 kryptografiskt säkert?
UUID v4 i sig är inte ett säkerhetsprimitiv — det är ett identifierarformat. Men när det genereras via crypto.randomUUID() (webbläsare eller Node.js) eller motsvarande OS-nivå-API:er, är den underliggande entropin kryptografiskt säker. Det innebär att UUID v4-värden är lämpliga för användning som sessionstoken eller idempotensnycklar, där oförutsägbarhet spelar roll. Använd inte Math.random()-baserade UUID-generatorer för säkerhetskänsliga sammanhang — använd bara API:er som uttryckligen hämtar från OS CSPRNG.
Kan två UUID v4 någonsin vara lika?
Teoretiskt ja, men praktiskt nej. Sannolikheten att generera en duplikat inom ett realistiskt dataset (miljarder ID:n) är astronomiskt liten — mycket mer osannolik än ett hårdvarufel som orsakar datakorruption. UUID v4-kollision behandlas som omöjlig i produktionssystemdesign. Om du verkligen behöver en nollkollisionsgaranti, använd en centraliserad räknare eller en databassekvens istället.
UUID v4 vs nanoid — vilket ska jag använda?
Båda är slumpmässiga ID-generatorer som stöds av en CSPRNG. De viktigaste skillnaderna:
- UUID v4 följer RFC 4122-standarden, känns igen av varje databas och ramverk, och kräver noll beroenden (inbyggd
crypto.randomUUID()). - nanoid använder ett URL-säkert alfabet och är kortare som standard (21 tecken vs 36). Användbart när URL-längd eller läsbarhet spelar roll. Kräver ett npm-paket.
Föredra UUID v4 när interoperabilitet med externa system spelar roll (API:er, databaser, loggningsinfrastruktur). Föredra nanoid när du vill ha kortare ID:n och kontrollerar hela stacken.
Ska jag lagra UUID:n som strängar eller binärt i databaser?
För de flesta databaser är lagring som en UUID- eller BINARY(16)-kolumn (16 byte) effektivare än en VARCHAR(36)-sträng (36 byte). PostgreSQL har en inbyggd uuid-typ. MySQL och MariaDB fungerar bra med BINARY(16) och UUID_TO_BIN() / BIN_TO_UUID()-hjälpfunktionerna. SQLite-användare lagrar vanligtvis som TEXT. Lagringsvalet påverkar inte unicitet eller korrekthet.
Varför har UUID v4 bindestreck — och kan jag utelämna dem?
Bindestreck är en del av den kanoniska UUID-representationen definierad av RFC 4122. De är rent kosmetiska — de bär ingen information och påverkar inte 128-bitarsvärdet. Att utelämna dem ger dig en kompakt 32-teckens hexsträng som är funktionellt ekvivalent. De flesta UUID-parsers accepterar båda formerna. Använd vid tveksamhet det kanoniska bindestreck-formatet för maximal kompatibilitet med tredjepartsverktyg och databaser.
const id = crypto.randomUUID() // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '') // "550e8400e29b41d4a716446655440000"