UUID v4 – 122 bits ren tilfeldighet i 36 tegn
UUID v4 er en 128-biters identifikator der 122 bits er ren tilfeldighet. De resterende 6 bitene er fastlagt: 4 bits markerer versjon (4), og 2 bits markerer varianten (10 i binær). Resultatet er en 36-tegns streng i formatet 8‑4‑4‑4‑12 med heksadesimale siffer – for eksempel f47ac10b-58cc-4372-a567-0e02b2c3d479.
Genereringen skjer lokalt i nettleseren via crypto.randomUUID eller tilsvarende API-er som trekker fra operativsystemets krypteringssikre tilfeldighetskilde. Ingen data sendes til en server. Hver gang du endrer en innstilling – antall, store bokstaver, bindestreker – kjøres genereringen på nytt umiddelbart.
Du kan be om mellom 1 og 100 UUID-er av gangen. Hver ID kan kopieres enkeltvis ved å klikke på den, eller du kan kopiere hele listen på én gang via en egen knapp. Statuslinjen viser «Ready.» før generering og «Generated.» etter, og ved kopiering av alle dukker «Copied all!» opp.
Hvorfor 122 bits tilfeldighet betyr noe
122 bits entropi gir astronomisk lav kollisjonssannsynlighet. For å ha 50 % sjanse for å oppleve én enkelt kollisjon må du generere omtrent 2,71 × 10¹⁸ UUID-er (omtrent 2,7 trillioner). Det er flere enn antall sandkorn på alle jordas strender. I praksis kan du trygt generere milliarder av UUID v4 uten å noensinne få en duplikat.
Denne egenskapen gjør UUID v4 ideell for distribuerte systemer der flere noder må lage unike identifikatorer uten å koordinere med hverandre. Ingen sentral server trenger å tildele ID-er, og ingen klokkesynkronisering er nødvendig. Hver node kan generere sine egne ID-er lokalt med visshet om at de er globalt unike.
Men – og dette er viktig – den samme tilfeldigheten som sikrer unikhet, skaper også problemer for databaseindekser.
Fragmentering av B-trær – den skjulte kostnaden
UUID v4 verdiene sorteres tilfeldig. Når du bruker dem som primærnøkkel i en database med B-tre-indeks (standard i MySQL, PostgreSQL, SQL Server), blir nye rader satt inn på tilfeldige steder i indeksen. Det fører til:
- Side-splitting – Indeksblokker må splittes oftere fordi nye nøkler ikke faller i rekkefølge.
- Økt indeksstørrelse – Splittede blokker etterlater tomrom.
- Dårligere hurtigbufferytelse – Indeksen blir mer fragmentert, og færre nøkler får plass per side.
Målbart: I tester med PostgreSQL kan innsetting av 10 millioner rader med UUID v4 være 3–5 ganger tregere enn med en monotont økende heltallsnøkkel. For svært store databaser (milliarder av rader) blir forskjellen enda mer uttalt.
Dette er grunnen til at mange databasearkitekter i dag foretrekker UUID v7 eller ULID for primærnøkler i distribuerte systemer. Disse formatene inneholder et tidsstempel som gjør at de sorteres kronologisk, noe som gir langt bedre indeksytelse. Men UUID v4 har fortsatt sin plass der tilfeldighet er viktigere enn sortering.
Når tilfeldighet vinner over sortering
Her er situasjonene der du bør velge UUID v4 over tidsbaserte alternativer:
Sikkerhet og uforutsigbarhet – UUID v4 er ideell for API-nøkler, sesjonstokener, request-ID-er og andre verdier der en angriper ikke skal kunne gjette neste ID. Tidsbaserte UUID-er avslører omtrent når ID-en ble generert, og i verste fall kan en angriper forutsi fremtidige ID-er.
Skjuling av antall poster – Med heltallsnøkler kan konkurrenter eller brukere anslå hvor mange rader du har (forskjellen mellom høyeste og laveste ID). UUID v4 avslører ingenting om volumet.
Offline-generering – Når enheter opererer uten nettverk (IoT-sensorer, mobile enheter), kan de generere UUID v4 lokalt uten å vente på en server. Tidsbaserte ID-er krever en pålitelig klokke, noe som kan være problematisk på enheter uten batteri eller med dårlig klokkesynkronisering.
Testing og data-generering – Verktøyet lar deg generere opptil 100 UUID-er på én gang, noe som er praktisk for å fylle testdatabaser med realistiske, unike nøkler.
Formatjusteringer du faktisk trenger
Verktøyet gir to brytere som påvirker utdataene:
Store bokstaver (Uppercase) – Heksadesimale siffer a–f vises som A–F. Dette er en kosmetisk endring, men den kan ha betydning for systemer som behandler store og små bokstaver ulikt. Noen API-er krever store bokstaver; andre bryr seg ikke. Ved å slå på store bokstaver får du strengen F47AC10B-58CC-4372-A567-0E02B2C3D479.
Bindestreker (Include hyphens) – Hvis du slår av bindestreker, fjernes de, og strengen blir 32 tegn lang: f47ac10b58cc4372a5670e02b2c3d479. Dette er nyttig for URL-er eller felt med tegnbegrensning der bindestreker er uønsket. Vær oppmerksom på at standard UUID-spesifikasjonen (RFC 4122) krever bindestreker i kanonisk form. Ved å fjerne dem avviker du fra standarden, men mange systemer aksepterer likevel formatet.
Begge bryterne utløser øyeblikkelig regenerering av alle ID-ene i listen.
Vanlige feil og misforståelser
UUID v4 er ikke egnet for sortering – Dette er den vanligste feilen. Hvis du forventer at UUID-er skal være kronologiske (slik auto-increment heltall er), vil du bli overrasket. UUID v4 gir ingen garantier om rekkefølge.
Kollisjon er ikke null – den er bare veldig liten – Noen feilaktig tror at UUID v4 aldri kan kollidere. Det stemmer ikke matematisk. Men sannsynligheten er så lav at den i praksis er neglisjerbar for alle realistiske scenarier.
Bruk av crypto.randomUUID i eldre nettlesere – Noen eldre nettlesere (Internet Explorer, gamle Safari) støtter ikke crypto.randomUUID. Verktøyet faller tilbake på alternative metoder for å sikre kompatibilitet.
Uppercase påvirker ikke kollisjonssannsynlighet – Store eller små bokstaver endrer ikke på de 122 tilfeldige bitene. Det er kun et visuelt valg.
FAQ
Hva er minimum og maksimum antall UUID v4 jeg kan generere? Du kan generere mellom 1 og 100 UUID-er per kjøring. Utenfor dette området aksepteres ikke verdien.
Hvordan kopierer jeg bare én UUID? Klikk på den spesifikke UUID-en i listen. Den kopieres umiddelbart til utklippstavlen. Verktøyet viser en egen melding når dette skjer.
Hva skjer når jeg endrer en innstilling? Alle ID-er regenereres umiddelbart. Det finnes ingen «generer»-knapp – endringene trer i kraft automatisk.
Er UUID v4 garantert unik? Nei, ingen UUID-versjon gir 100 % garanti. Men med 122 bits tilfeldighet trenger du å generere over 2,7 × 10¹⁸ ID-er for å ha 50 % sjanse for én kollisjon. For praktiske formål er det så godt som garantert unikt.
Kan jeg bruke dette verktøyet uten internettforbindelse? Ja. All generering foregår lokalt i nettleseren din. Når siden først er lastet (eller som en PWA), trengs ingen nettilgang.
Hva er forskjellen mellom UUID v4 og UUID v7? UUID v7 bruker 48 bits for et tidsstempel og 74 bits tilfeldighet. Det gir kronologisk sortering og bedre databaseytelse, men avslører genereringstidspunktet. UUID v4 er rent tilfeldig og avslører ingenting om når det ble laget.