UUID v4 – struktur och uppbyggnad
UUID v4 är en av de vanligaste identifierarna inom mjukvaruutveckling. Varje identifierare består av 36 tecken i formatet 8‑4‑4‑4‑12, där de 32 hexadecimala tecknen grupperas med fyra bindestreck. Av de 128 bitarna är 122 helt slumpmässiga och genereras med kryptografiskt stark slump från webbläsaren. De återstående sex bitarna är fasta: fyra bitar anger varianten (10xx) och två bitar anger versionen (0100 för v4). Det innebär att varje UUID v4 garanterat har samma struktur och alltid börjar med en siffra mellan 0 och 4 i den fjärde teckenpositionen om man tittar på det hexadecimala värdet: till exempel xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx där y alltid är 8, 9, a eller b (binärt 10xx).
På den här sidan kan du styra två formatdetaljer som är specifika för UUID: versaler och bindestreck. Om du aktiverar versaler visas bokstäverna a–f som A–F i utskriften. Om du stänger av bindestreck blir strängen 32 tecken lång – fortfarande samma 122 bitars slump, men i ett mer kompakt format som ofta används i URL:er eller som primärnycklar i system där de fyra bindestrecken är överflödiga. Dessa växlingar påverkar bara visningen, inte slumptalet i sig.
Slumpmässighet och kollisionssannolikhet
122 bitars slumpmässighet innebär att antalet möjliga unika UUID v4 är 2¹²², vilket är ungefär 5,3 × 10³⁶. För att sätta det i perspektiv: om du genererade en miljard unika UUID per sekund i 100 år skulle sannolikheten att få en enda kollision fortfarande vara försvinnande liten – långt under 10⁻¹² i praktiska system. Detta beror på födelsedagsparadoxen: sannolikheten för en kollision växer kvadratiskt med antalet genererade ID, men med 122 bitar krävs astronomiska mängder innan risken blir mätbar.
För utvecklare innebär detta att UUID v4 är en trygg standard för att skapa unika identifierare utan central samordning. Det är därför vanligt för API-nycklar, sessions-ID:n, händelse-ID:n och objekt som skapas i distribuerade system där ingen databas eller server kan garantera unicitet genom att räkna upp sekventiella tal. De 122 slumpbitarna kommer från webbläsarens crypto.randomUUID eller motsvarande – i praktiken samma kryptografiskt starka slumpmotor som används för nyckelgenerering. Allt sker lokalt på klienten; inget skickas över nätverket.
Inverkan på databasindexering
Den största praktiska nackdelen med UUID v4 är effekten på B‑trädindex. När man använder ett slumpmässigt UUID som primärnyckel i en databas (t.ex. MySQL, PostgreSQL, SQL Server) hamnar varje ny rad på en slumpmässig plats i indexet. Det leder till kraftig indexfragmentering eftersom nya poster sällan läggs till i slutet av trädet. Varje infogning kan kräva omstrukturering av flera noder, vilket dramatiskt ökar skrivlatensen och minskar genomströmningen.
I system med hög skrivbelastning kan detta bli en flaskhals. Många databaser har optimeringar för sekventiella nycklar (t.ex. autoincrement eller UUID v7 med tidsstämpel), men UUID v4 motverkar dessa optimeringar fullständigt. Fragmenteringen kan dämpas genom att regelbundet omindexera tabellen eller använda klustrade index på andra kolumner, men det är alltid en avvägning.
För den som ändå väljer UUID v4 som primärnyckel är det viktigt att databasen stöder UUID som en egen datatyp (inte bara som CHAR(36)), eftersom det minskar lagringsutrymmet och förbättrar sorteringsprestanda. Vissa databaser som PostgreSQL lagrar UUID binärt och kan därmed hantera dem effektivare än en textsträng.
Skillnader mot tidsbaserade identifierare
Till skillnad från UUID v4 har versionerna v7 och v1 en inbyggd tidsstämpel. UUID v7 är det modernare alternativet och innehåller 48 bitar Unix-tid i millisekunder, följt av slumpmässiga bitar. Det gör att två v7-ID:n som genereras i samma millisekund fortfarande sorterar ungefär i ordning, medan v4-ID:n alltid sorterar helt godtyckligt. ULID bygger på samma princip – tidsstämpel först, slump efter – och är dessutom kodat i en liten teckenuppsättning (Crockfords Base32) som är skiftlägesokänslig och undviker tvetydiga tecken som I och L.
Vilken typ man väljer beror på användningsområdet. UUID v4 är optimalt när man inte vill avslöja tidpunkten för skapandet – till exempel för API-nycklar eller spårnings-ID där en angripare inte ska kunna gissa när en användare registrerade sig. Tidsbaserade format är bättre när man behöver sortera efter skapelsetid eller när databasens skrivprestanda är kritisk. Den här sidan erbjuder även UUID v7, ULID och NanoID i samma gränssnitt, så du kan jämföra resultaten direkt.
Användningsfall för icke‑sekventiella ID:n
Det finns flera situationer där slumpmässiga ID:n är överlägsna sekventiella. För det första förhindrar de gissning av antalet poster – en angripare kan inte räkna ut hur många användare eller beställningar som finns genom att iterera ID:n. För det andra fungerar de i distribuerade system utan central räknare; varje nod kan generera unika ID:n oberoende av de andra, vilket eliminerar behovet av synkronisering eller en gemensam sekvensdatabas.
Exempel: en mikroservices-arkitektur där flera tjänster skapar händelser som senare aggregeras i en databas. Varje tjänst kan generera UUID v4 lokalt utan att vänta på en databas. Samma princip gäller för offline-first-applikationer där en mobil enhet skapar objekt som synkas senare – UUID v4 garanterar unicitet även när enheten är offline. Säkerhetsingenjörer använder dem som API-nycklar för att göra det praktiskt taget omöjligt att gissa giltiga token, även om databasen inte är krypterad.
Anpassning av format och kompatibilitet
Standardformatet med bindestreck (8‑4‑4‑4‑12) är mest läsbart och används i RFC 4122. Men i vissa sammanhang kan bindestrecken vara oönskade. Om du genererar ID:n för en URL-sökväg eller för användning i JSON-objekt där teckenantalet spelar roll, är det ofta bekvämare att ta bort dem och få en 32‑teckens hexadecimal sträng. Vissa databaser lagrar UUID mer effektivt binärt än som text, vilket gör hypenerna överflödiga – de återinförs vid visning.
Versaler påverkar endast läsbarheten och eventuell kompatibilitet med gamla system som är skiftlägeskänsliga. Hexadecimala siffror är skiftlägesokänsliga i de flesta databaser och programmeringsspråk, men om din applikation använder strängjämförelse måste du vara konsekvent. Vissa verktyg som UI-komponenter eller loggsystem kan förvänta sig små bokstäver. Att kunna växla mellan format direkt i gränssnittet gör det enkelt att testa olika varianter utan att modifiera koden.
Generering i webbläsaren och integritet
Alla identifierare genereras lokalt i din webbläsare med hjälp av crypto.randomUUID eller motsvarande API från Web Crypto. Inget data skickas till en server. Det innebär flera fördelar: noll latens avrundat till nätverkstidsfördröjning, full kontroll över utdataformat, och framför allt integritet – ingen tredje part kan se vilka ID:n du genererar eller hur många du skapar.
När du ändrar någon av inställningarna (antal, avaktivera bindestreck, välj versaler) återskapas hela listan omedelbart. Du kan kopiera ett enskilt ID genom att klicka på det, eller kopiera hela listan med en knapp – efteråt visas ett kort meddelande som "Kopierat alla!". Statusfältet växlar mellan "Redo" och "Genererad" för att spegla om listan är aktuell.
För testare, databasdesigners och backend-utvecklare innebär detta ett omedelbart sätt att producera tusentals realistiska, unika identifierare utan att skriva ett skript eller riskera att få dubbletter från slumptalsgeneratorer av lägre kvalitet. Och eftersom resultatet är 122 bitar av verklig slump per ID, är det lämpligt även för säkerhetskritiska sammanhang.
FAQ – vanliga frågor om UUID v4
Hur många ID:n kan jag generera åt gången?
Du anger ett antal mellan 1 och 100. Om du behöver fler, generera flera batchar – varje ID är oberoende och risken för kollision är försumbar även över miljarder.
Är det sant att två UUID v4 alltid är unika?
Nej, det är inte garanterat matematiskt, men sannolikheten för en kollision är så extremt låg att det i praktiken är omöjligt. För att ens få en 50% risk att få en kollision behöver man generera över 2,4 × 10¹⁸ ID:n (enligt födelsedagsparadoxen för 122 bitar).
Kan jag använda UUID v4 som primärnyckel i en MySQL-databas?
Ja, det fungerar, men var medveten om indexfragmenteringen som beskrivs ovan. Om skrivprestanda är viktig, överväg att använda UUID v7 istället eller använda ett autoincrement-fält som surrogatnyckel.
Vad händer om jag klickar på ett enskilt ID?
Det kopieras till ditt urklipp. Därefter kan du klistra in det var som helst. Sidan visar en kort bekräftelse.
Förändras ID:n om jag slår på eller av versaler?
Ja, omedelbart – alla ID:n genereras om med den nya inställningen. Varje ny inställning (antal, versaler, bindestreck, format) tvingar fram en ny slumpgenerering.
Är det säkert att använda denna generator för produktionsnycklar?
Ja. Slumpen kommer från webbläsarens crypto.randomUUID, som uppfyller de krav som ställs av NIST för kryptografisk slumpgenerering. Ingenting skickas över nätverket. Du kan vara helt trygg med att ID:n är oförutsägbara och unika för ditt syfte.