Generera UUID v4, UUID v7, ULID och NanoID-21 med ett enda klick. Alla värden beräknas lokalt i webbläsaren via crypto.getRandomValues(), utan någon server.
Välj variant och antal, listan uppdateras live. 1 till 100 värden åt gången.
100% i din webbläsare: Denna sida är ren HTML+JavaScript. Det finns ingen serverroundtrip, varje UUID dras lokalt via Web Crypto API (`crypto.getRandomValues`).
Vad är en UUID?
En UUID (Universally Unique Identifier, RFC 4122 / RFC 9562) är en 128-bitars identifierare som skapas utan central myndighet och ändå är praktiskt taget globalt unik. Textformen är 32 hexsiffror, separerade i fem grupper `8-4-4-4-12` med bindestreck, totalt 36 tecken inklusive skiljetecken.
Det finns flera versioner. v1 använder tid + MAC-adress (integritetsproblem), v3 och v5 härleder ID:t från ett namn plus namespace (deterministiskt), v4 är rent slumpmässig (modern standard) och v7 är tidsordnad och löser databasindex-problemet hos v4.
Vid sidan av dem är ULID och NanoID populära icke-IETF-alternativ. ULID är en sorterbar 26-teckenssträng, NanoID en kort URL-säker ID (ofta 21 tecken). Vilken variant som passar beror främst på planerad lagring och URL-layout.
v4 vs. v7 vs. ULID vs. NanoID
En snabb översikt över de fyra viktigaste varianterna:
Format
Längd
Alfabet
Sorterbar
Främsta användningsområde
UUID v4
36 (32 hex + 4 dash)
0-9 a-f
nej (slumpmässig)
universell standard, bra för interna ID:n
UUID v7
36
0-9 a-f
ja (tidsordnad, 48-bitars ms)
primärnycklar i DB:er (B-tree-vänlig)
ULID
26
0-9 A-Z (ohne I, L, O, U)
ja (tidsordnad)
URL:er / loggar, mer läsbar än hex
NanoID-21
21
A-Z a-z 0-9 _ -
nej (slumpmässig)
korta URL-sluggar, share-länkar
Crockford base32 (ULID) utelämnar I, L, O och U för att undvika förväxling med 1, 0 och V.
När väljer jag vilken variant?
Tumregler från verklig användning:
UUID v4: solid standard för osorterade ID:n (sessioner, idempotency-nycklar, korrelations-ID:n). 122 bitars entropi, kollisionssannolikheten absurt låg.
UUID v7: rekommenderad för databasprimärnycklar. De första 48 bitarna är en unix-ms-tidsstämpel, så nya rader hamnar i slutet på B-tree-index (lågt page-split-tryck, god locality).
ULID: när du vill ha ett tidsordnat ID som förblir läsbart i URL:er och loggar. 26 tecken, kortare än UUID, men inte RFC-standard. Vissa verktygsstackar saknar inbyggt stöd.
NanoID-21: ideal för synliga share-länkar och sluggar. 21 tecken, URL-säker, cirka 126 bitars entropi (mer än UUID v4) på mycket kortare längd.
Varför inte auto-increment-ID:n i produktion?
Auto-increment-ID:n (t.ex. `BIGINT IDENTITY` eller `SERIAL`) är enkla, snabba och indexvänliga, men misslyckas med flera moderna krav:
De läcker affärsmått: en konkurrent som ser två på varandra följande ordernummer förstår direkt hur många order som flödar per dag.
De ger inget botskydd: `/users/123` är vad varje brute-force-crawler går igenom från 1 till n, varje ID är trivialt uppräkningsbart.
De försvårar distribuerade system: en multi-region-uppsättning eller offline-klienter (mobilappar, edge) måste samordna sekvenser eller köra en central ID-tjänst. UUID:er undviker det helt.
De kan inte tilldelas på klienten: en frontend kan inte reservera ett auto-increment-ID före INSERT (t.ex. för optimistic UI). UUID:er genereras i klienten och skickas vidare via `INSERT`.
De är inte testvänliga: tester som rullar tillbaka data krockar med sekvensvärden eller lämnar luckor. UUID:er förblir stabila genom tester.
Rekommendation: behåll auto-increment för interna, rent operativa tabeller (migrationslog, räknare), och använd UUID v7 som standardprimärnyckel för domänenheter (User, Order, Document).
UUID-prestanda i databaser
Den vanligaste invändningen mot UUID:er är "de förstör mina indexprestanda". Det stämde delvis förr men är antingen lätt att åtgärda eller helt undvikt med v7/ULID.
Det verkliga problemet är inte storleken (16 byte vs. 8 byte för en bigint), utan den slumpmässiga insert-ordningen: med v4 hamnar varje insert någonstans mitt i B-treet, vilket orsakar page splits, kalla cachar och write amplification.
Lösning 1: använd UUID v7 eller ULID i stället för v4. De tidsordnade bitarna säkerställer att nya rader hamnar i slutet på indexet.
Lösning 2: i PostgreSQL använd typen `uuid`, i MySQL `BINARY(16)` (i stället för `CHAR(36)`), vilket sparar 20 byte per rad och gör jämförelser heltalssnabba.
Lösning 3: lägg det clustered index på en annan nyckel (t.ex. monotont stigande) och behåll UUID som sekundärnyckel. Vanligt i MS SQL Server.
Lösning 4: vid bulk-inserts, infoga i sorterad ordning, eller använd en bulk loader som bygger om indexet i slutet.
På senare Postgres- och MySQL-versioner är UUID v7 som primärnyckel snabbare än v4 i nästan varje arbetsbelastning och ungefär i nivå med bigint auto-increment, samtidigt som alla fördelar bibehålls (inget läckage, distribuerad skapande, klientbaserat).
Backends med hög genomströmning hos KernelHost
Den som lagrar miljontals UUID:er per dag i en databas vill ha NVMe-lagring, ECC-RAM och stabil uplink. KernelHost driver egna dedikerade och VPS-servrar i Frankfurt FRA01 med DDoS-skydd, IPv4 + IPv6 och 1 Gbit/s. Låg RTT till tyska och österrikiska kunder, rättvisa priser. Företagssäte Wien (AT), datacenter Frankfurt (DE).
UUID FAQ
Är UUID:erna som genereras här kryptografiskt säkra?
Ja. UUID v4 använder `crypto.randomUUID()`, övriga varianter använder `crypto.getRandomValues()`. Båda är CSPRNG-källor lämpliga för tokens, nycklar och ID-generering.
Hur sannolik är en kollision?
UUID v4 (122 bitars entropi) behöver cirka 2,71 miljarder ID:n innan 50%-kollisionsmarkeringen nås (födelsedagsparadoxen). I vardagsbruk i praktiken noll.
Är UUID v7 redan stabil?
Ja. UUID v7 är officiellt standardiserad i RFC 9562 (maj 2024). Postgres 17 har inbyggt v7-stöd och bibliotek finns i alla större språk.
Varför visas ingen tidsstämpel bredvid UUID v4 och NanoID?
Dessa varianter kodar ingen tidsstämpel. Endast UUID v7 och ULID är tidssorterbara, så bara där visas ms-tidsstämpeln som extra information.
Sparar sidan de genererade ID:erna någonstans?
Nej. Listan finns bara i DOM:en på denna enda sida. En omladdning genererar nya ID:n. Det finns ingen serverroundtrip, ingen `fetch`, ingen spårning. Endast senaste variant + antal sparas i `localStorage` så att nästa besök startar i rätt läge.
Kan jag generera mer än 100 ID:n åt gången?
UI:t är begränsat till 100 för att hålla renderingen snabb. För skriptdrivna behov (t.ex. testdata) anropa `crypto.randomUUID()` direkt i Node eller valfritt språk.
Kan verktyget även skapa UUID v3/v5?
Just nu inte. v3 och v5 är deterministiska (hash över namespace + namn) och hör hemma i serverkod. Om du behöver dem, hör av dig eller använd ett bibliotek som `uuid` i Node eller `python-uuid`.
Ska jag spara UUID:er som strängar eller bytes?
Om drivrutinen känner till en inbyggd UUID-typ (Postgres, .NET, MongoDB), använd den. Annars välj `BINARY(16)` framför `CHAR(36)`: 20 byte sparat per rad, snabbare jämförelser, ingen extra padding eller cast overhead.
Alla KernelHost-produkter
Behöver du mer än bara verktyg? Kolla in vårt kommersiella hostingutbud.