> uuidv7 generator <
// Tidsordnade, sorterbara UUID:er (RFC 9562, 2024) — 48-bitars Unix-ms-tidsstämpel + 74 slumpmässiga bitar, genererade lokalt
// AVKODA / INSPEKTERA EN UUIDV7
Klistra in valfri UUID nedan för att extrahera dess inbäddade tidsstämpel, version och variant. Fungerar med v7 och rapporterar om indata är en annan UUID-version.
Specifikationsenlig UUIDv7
Implementerar det tidsordnade UUID-formatet från RFC 9562 (maj 2024): 48-bitars Unix-millisekundtidsstämpel, 4-bitars version 7, 12-bitars rand_a, 2-bitars variant, 62-bitars rand_b. Verifierad mot specifikationens testvektorer.
Kronologisk sorteringsordning
Sortera numeriskt eller lexikografiskt och du får insättningsordningen — perfekt för B-trädsprimärnycklar, tidsserieindex och loggkorrelation. Inga fler slumpmässiga v4-siduppdelningar eller fragmenterade index.
Monotonicitet inom samma millisekund
När flera UUID:er hamnar i en millisekund ökas den slumpmässiga delen strikt så att utdata förblir sorterade inom den ms:en. Stäng av för ren RFC 9562 Metod 1 (slumpmässig fyllning) om du föredrar det.
Inspektera valfri UUIDv7
Klistra in en v7-UUID så extraherar avkodaren den inbäddade tidsstämpeln (ms + ISO 8601), versionsbitar, variantbitar och fälten rand_a / rand_b. Användbart för felsökning, loggarkeologi och granskningsspår.
// OM UUIDV7
Så fungerar UUIDv7:
En UUIDv7 är en 128-bitars identifierare uppbyggd som unix_ts_ms (48) | ver (4) | rand_a (12) | var (2) | rand_b (62). De första 48 bitarna är den aktuella Unix-tidsstämpeln i millisekunder, big-endian, vilket gör UUID:n monotont ökande i tid. De följande 4 bitarna kodar versionen (binärt 0111 = decimalt 7), så den tredje bindestrecksavgränsade gruppen börjar alltid med siffran 7. rand_a är 12 slumpmässiga bitar som används för sub-millisekundupplösning eller som extra entropi. Det 2-bitars variantfältet är fastställt till 10 (så det första tecknet i den fjärde gruppen är alltid 8, 9, a eller b). De återstående 62 bitarna (rand_b) kommer från crypto.getRandomValues() vid varje generering. Den totala entropin per UUID är 74 slumpmässiga bitar, vilket är kollisionsbeständigt för varje realistisk genereringstakt.
Exempel:
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55 (ts=2024-05-08T15:00:00.000Z)
Standarder och referenser:
- >RFC 9562 — Universally Unique IDentifiers (UUIDs), maj 2024 (ersätter RFC 4122, definierar v6/v7/v8)
- >RFC 4122 — den ursprungliga UUID-specifikationen från 2005 (fortfarande auktoritativ för v1-v5)
- >Web Crypto API (W3C) —
crypto.getRandomValues()CSPRNG som används för de 74 slumpmässiga bitarna - >PostgreSQL
gen_random_uuid()-beteende (v4 som standard, v7 i pgcrypto-tillägg / forkar) - >draft-peabody-dispatch-new-uuid-format — det ursprungliga v6/v7/v8-förslaget som blev RFC 9562
Varför använda UUIDv7:
- >Databasprimärnycklar med insättningslokalitet — sidor förblir packade, index fragmenteras inte
- >Ersätter ett par av sekvens + UUID: en kolumn, sorterbar OCH globalt unik
- >Ersätter v4-primärnycklar i skrivintensiva tabeller för att lösa problemet med siduppdelning vid slumpmässig insättning
- >Loggkorrelations-ID:n som sorteras efter skapelsetid utan en separat tidsstämpelkolumn
- >Distribuerade system där flera skrivare behöver ordnade ID:n utan en koordinator
- >Event sourcing / append-only-loggar där kronologisk ordning är det naturliga indexet
- >S3- / objektlagringsnycklar där prefixsortering matchar insättningsordningen
- >Ersätter Snowflake / KSUID / ULID där ett standardformat är att föredra
Relaterade verktyg:
- >UUID-generator — genererar v4 (slumpmässig) och v1 (tidsstämpel) när du inte behöver v7:s sorteringsordning
- >GUID-generator — samma identifierare under Microsoft-namngivningen
- >Tidsstämpelkonverterare — konverterar de inbäddade Unix-ms tillbaka till lokal tid / ISO 8601
- >Epoch-konverterare — inspektera 48-bitars tidsstämpeldelen i valfri tidszon
- >Lösenordsgenerator — kryptografiskt slumpmässiga tokens när sorterbarhet inte krävs
// EXEMPELUTDATA
Enskild UUIDv7 genererad nu
count=1, format=standard, timestamp=current
output:
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
Massbatch med monotonicitet i samma millisekund
count=5, format=standard, monotonic=on
output:
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a56 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a57 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a58 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a59
Anpassad historisk tidsstämpel — påfyllning av en migrering
count=1, timestamp=custom, value=1577836800000 (2020-01-01)
output:
016f5e66-e800-7c9a-b403-2f1d4a7c91ee
Kompakt format för URL:er / filnamn
count=1, format=no-hyphens
output:
018f5c2e90c07a4fb6ee8dfe3c2b0a55
Avkodad UUIDv7 — inspektera de inbäddade fälten
input = 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
output:
ts_ms = 1715180400000 ISO = 2024-05-08T15:00:00.000Z ver = 7 var = 10 (RFC 4122) rand_a = 0xa4f rand_b = 0x36ee8dfe3c2b0a55
// IMPLEMENTERA DET SJÄLV
De flesta språk har antingen en stdlib-hjälpare eller en implementering i en fil för UUIDv7 sedan RFC 9562 kom 2024. Nedan finns de kanoniska recepten du kan släppa in i din kodbas — i webbläsar-JS, Node.js, Go, Python och PostgreSQL.
UUIDv7 i ren webbläsar-/Node-JS — RFC 9562-uppbyggnad
function uuidv7() {
const ts = BigInt(Date.now());
const rand = new Uint8Array(10);
crypto.getRandomValues(rand);
const b = new Uint8Array(16);
b[0] = Number((ts >> 40n) & 0xFFn);
b[1] = Number((ts >> 32n) & 0xFFn);
b[2] = Number((ts >> 24n) & 0xFFn);
b[3] = Number((ts >> 16n) & 0xFFn);
b[4] = Number((ts >> 8n) & 0xFFn);
b[5] = Number( ts & 0xFFn);
b[6] = (rand[0] & 0x0F) | 0x70; // version = 7
b[7] = rand[1];
b[8] = (rand[2] & 0x3F) | 0x80; // variant = RFC 4122
for (let i = 9; i < 16; i++) b[i] = rand[i - 6];
const h = Array.from(b, x => x.toString(16).padStart(2,'0')).join('');
return `${h.slice(0,8)}-${h.slice(8,12)}-${h.slice(12,16)}-${h.slice(16,20)}-${h.slice(20)}`;
}
// usage:
const id = uuidv7();
console.log(id); // -> '018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55'
// generate a batch and verify chronological sort:
const batch = Array.from({ length: 5 }, uuidv7);
batch.sort(); // sorts by creation time without a separate timestampNode.js v26.1.0+ — inbyggd crypto.randomUUIDv7()
import { randomUUIDv7 } from 'node:crypto';
// Added in Node.js v26.1.0 (2026-05-07).
// Returns an RFC 9562 version 7 UUID. The first 48 bits encode a
// millisecond Unix timestamp; the rest is CSPRNG output.
const id = randomUUIDv7();
// -> '018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55'
// The CSPRNG output is cached for performance: Node generates enough
// entropy upfront for the next ~128 UUIDs. Pass disableEntropyCache: true
// when you need each call to draw fresh randomness, e.g. directly after
// a fork() or in tight high-security loops.
const freshId = randomUUIDv7({ disableEntropyCache: true });
// IMPORTANT: per the Node docs, "the embedded timestamp relies on a
// non-monotonic clock and is not guaranteed to be strictly increasing."
// If two UUIDs land in the same millisecond OR the system clock steps
// backwards, the IDs may not sort in creation order. Use a userland
// monotonic-v7 library (e.g. uuidv7 on npm) when strict ordering matters.Go — google/uuid v1.6+ levererar UUIDv7 nativt
package main
import (
"fmt"
"github.com/google/uuid"
)
func newID() uuid.UUID {
id, err := uuid.NewV7()
if err != nil {
panic(err)
}
return id
}
func main() {
id := newID()
fmt.Println(id.String()) // 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
fmt.Println(id.Time()) // embedded creation timestamp
}Python 3.13+ — stdlib uuid.uuid7()
import uuid
# Python 3.13 added uuid7() and uuid8() to the standard library.
uid = uuid.uuid7()
print(uid) # 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
print(uid.version) # 7
# For older Python use the 'uuid7' or 'uuid-utils' PyPI packages, or:
# from uuid_extensions import uuid7PostgreSQL 18+ — nativ uuidv7()-funktion
-- PG 18 ships uuidv7() natively. Use it as a primary key default:
CREATE TABLE events (
id uuid PRIMARY KEY DEFAULT uuidv7(),
body jsonb,
ts timestamptz NOT NULL DEFAULT now()
);
-- For older Postgres, install the pg_uuidv7 extension or generate client-side.
-- Migration tip: keep INDEX on (id) only — v7 already sorts chronologically,
-- so a separate (created_at) index is usually redundant.// VANLIGA FALLGROPAR
> UUIDv7 läcker skapelsetiden — använd den inte för ogenomskinliga tokens
De första 48 bitarna av varje v7 är en Unix-millisekundtidsstämpel. Alla som ser UUID:n kan avkoda när posten skapades, hastigheten med vilken ID:n utfärdas och (med flera stickprov) approximera serverklockan. Det är okej för interna databasprimärnycklar och logg-ID:n, men för URL:er för lösenordsåterställning, delningslänkar, sessions-ID:n eller inbjudningskoder, använd istället UUIDv4 eller en CSPRNG-genererad slumpmässig sträng.
> Klockregression bryter monotonicitet
Om systemklockan hoppar bakåt (NTP-steg, VM-migrering, skottsekund) kan naivt genererade v7-UUID:er producera värden som sorteras före tidigare utfärdade ID:n. RFC 9562 §6.2 rekommenderar Metod 2 (monoton slumpmässig): håll reda på den senast genererade UUID:n och, när tidsstämpeln inte avancerar, öka den slumpmässiga delen istället. Det här verktygets Monoton-omkopplare gör precis det.
> v7 är inte en direkt ersättning för v4 i säkerhetskänsliga sammanhang
Slumpmässigt utseende ID:n (v4) används ofta av misstag som bearer-tokens: ”om du känner till UUID:n kan du läsa raden”. v7 har bara 74 slumpmässiga bitar och ett förutsägbart tidsstämpelprefix, vilket fortfarande är kollisionsbeständigt men ger mycket mindre oförutsägbarhet än v4:s 122 slumpmässiga bitar. Om något behandlas som en capability, generera ett separat kryptografiskt token istället för att återanvända v7-primärnyckeln.
> Strängjämförelse fungerar bara i gemener med bindestreck
v7:s kronologiska sortering bygger på lexikografisk jämförelse av den kanoniska 36-tecken långa strängen med gemener — eller på byte-för-byte-jämförelse av det underliggande 16-byte-värdet. Att blanda versaler och gemener, ta bort bindestreck halvvägs eller lagra vissa rader som {...}-inramade och andra utan kommer alla att producera en sorteringsordning som inte längre matchar skapelsetiden. Välj en kanonisk form per kolumn och tvinga fram den med en CHECK-begränsning.
> 48-bitars tidsstämpel slår runt år 10889
2^48 millisekunder är ungefär 8 925 år efter Unix-epoken — tidsstämpelfältet svämmar över den 2 augusti 10889 UTC. Om din kod hävdar att den inbäddade tidsstämpeln ligger inom ett rimligt intervall, sätt den övre gränsen till 281 474 976 710 655 ms (det maximala som ett 48-bitars heltal utan tecken kan rymma) istället för att hårdkoda ett nära-framtida år som kommer att vara fel om ett sekel.
>> vanliga frågor
F: Vad är UUIDv7?
S: UUIDv7 är en 128-bitars identifierare definierad i RFC 9562 (maj 2024) som kombinerar en 48-bitars Unix-millisekundtidsstämpel med 74 bitar slumpmässighet och standardbitarna för version + variant. Resultatet är ett globalt unikt ID som också sorteras kronologiskt efter skapelsetid — det bästa av två världar. Det utformades specifikt för att lösa databasindexproblemet som orsakas av slumpmässiga UUIDv4-primärnycklar, där varje insättning hamnar på en annan B-trädssida och orsakar massiv skrivförstärkning.
F: Hur skiljer sig UUIDv7 från UUIDv4?
S: UUIDv4 är helt slumpmässig (122 slumpmässiga bitar) och har ingen struktur utöver version- + variantfälten. Två v4:or genererade en mikrosekund isär sorteras till vitt skilda positioner, vilket är utmärkt för oförutsägbarhet men hemskt för B-trädsindex. UUIDv7 placerar en 48-bitars Unix-millisekundtidsstämpel först, så v7:or genererade nära i tiden sorteras också nära i lagringen. Kompromiss: v7 läcker skapelsetiden och har bara 74 slumpmässiga bitar istället för 122 — fortfarande kollisionsbeständig, men olämplig som hemlig token.
F: Bör jag migrera från UUIDv4 till UUIDv7?
S: För interna databasprimärnycklar på skrivintensiva tabeller — ja, nästan alltid. Den indexfragmentering som v4 orsakar kan överstiga kostnaden för själva frågorna, särskilt på PostgreSQL eller MySQL med InnoDB-klustrade index. För tokens som exponeras för användare, bäddas in i URL:er eller behandlas som capabilities (”om du känner till UUID:n kan du komma åt resursen”), behåll v4 eller använd en separat slumpmässig token — v7 läcker skapelsetiden. Ett vanligt mönster är v7-primärnycklar för interna joins plus en separat slumpmässig slug för den publika URL:en.
F: Är UUIDv7 samma sak som ULID, KSUID eller Snowflake?
S: Konceptuellt lika — alla fyra är tidsordnade ID:n — men bitlayouterna och kodningarna skiljer sig åt. ULID använder Crockford base32 och en annan millisekundlayout. KSUID kodar en 32-bitars tidsstämpel + 128-bitars nyttolast som 27 base62-tecken. Snowflake är ett 64-bitars Twitter-specifikt ID med worker-ID:n. UUIDv7 är den IETF-standardiserade motsvarigheten, kodad i den kanoniska 8-4-4-4-12-hex-formen, så att varje UUID-bibliotek, databas-UUID-typ och JDBC/ODBC-drivrutin redan förstår den. Om du börjar om från början 2025+, föredra v7 — det är standarden.
F: Hur många UUIDv7:or kan jag generera per millisekund före kollisioner?
S: Inom en enskild millisekund ger endast de 74 slumpmässiga bitarna (12 i rand_a + 62 i rand_b) unikhet. Enligt födelsedagskollisionsgränsen kan du generera ungefär 2^37 ≈ 137 miljarder v7:or i samma ms innan det finns 50 % kollisionsrisk — i praktiken obegränsat för alla realistiska system. Mellan millisekunder skiljer själva tidsstämpeln, så den globala kollisionsrisken under ett systems livstid är försumbar. Med Monoton-omkopplaren på är kollisioner inom samma millisekund noll per konstruktion (den slumpmässiga delen ökas).
F: Kan jag extrahera tidsstämpeln från en UUIDv7?
S: Ja — tidsstämpeln är de första 48 bitarna, vilket är de första 12 hex-tecknen med bindestrecken borttagna. Sammanfoga de tre första bindestrecksgrupperna (8 + 4 = 12 hex digits), tolka som ett hexadecimalt heltal, och du har Unix-tidsstämpeln i millisekunder. Använd avkodaren ovan för att göra detta interaktivt, eller i kod: parseInt(uuid.replace(/-/g,'').slice(0,12), 16). Resultatet är millisekundsögonblicket då UUID:n genererades, exakt enligt systemklockan vid den tidpunkten.
F: Hur ser versionssiffran ut i en UUIDv7?
S: Den tredje bindestrecksavgränsade gruppen börjar alltid med siffran 7. Till exempel: 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55. Den fjärde gruppen börjar alltid med 8, 9, a eller b — det är de fyra möjliga värdena när de översta två bitarna är 10 (RFC 4122-varianten). Om versionssiffran inte är 7 är UUID:n av en annan version (vanligen 4 för slumpmässig eller 1 för tidsbaserad v1) och sorteras inte kronologiskt.
F: Stöder PostgreSQL / MySQL UUIDv7 nativt?
S: PostgreSQL 18 (släppt september 2025) levererar uuidv7() som en inbyggd funktion. Tidigare versioner behöver pg_uuidv7-tillägget eller generering på klientsidan. MySQL 8.x har ingen nativ v7; använd hjälparen UUID_TO_BIN(uuid, 1) (som byter tidsstämpelbytes för sorteringsordning) endast för v1 — för v7 generera på klientsidan. SQL Server, Oracle och SQLite förväntar sig alla generering av v7 på klientsidan. De flesta ORM:er (Hibernate, Entity Framework, Sequelize, Prisma, SQLAlchemy) stöder nu v7 antingen nativt eller via ett plugin.
F: Är det monotona alternativet förenligt med RFC 9562?
S: Ja. RFC 9562 §6.2 beskriver uttryckligen tre metoder för att säkerställa ordning inom samma millisekund: (1) slumpmässig fyllning, (2) monoton slumpmässig — öka en räknare när tidsstämpeln inte avancerar, (3) sub-millisekundtidsstämpelprecision. Kryssrutan Monoton i det här verktyget implementerar metod 2: när två UUID:er delar samma 48-bitars tidsstämpel sätts den andras slumpmässiga del till previous_random + 1 istället för att dras på nytt. Detta garanterar strikt ordning för batchgenerering samtidigt som det förblir fullt specifikationsenligt.
F: Skickas mina data någonstans?
S: Nej. All UUIDv7-generering, -avkodning, -sortering, -kopiering och -nedladdning sker helt i din webbläsare som ren JavaScript. Sidan gör aldrig en nätverksbegäran när du klickar på GENERERA, AVKODA, KOPIERA eller LADDA NER — du kan verifiera det med nätverksfliken i din webbläsares DevTools. Vi loggar inte tidsstämplar, anpassade seeds, genererade UUID:er eller avkodade utdata. Sidan i sig är statisk HTML som levereras från ett CDN, så ingen indata når någonsin vår infrastruktur. Detta gör verktyget säkert att använda för produktionsdatabас-ID:n, interna loggar eller andra data som du helst inte vill skicka genom en tredjepartsserver.
F: Kan jag använda UUIDv7 i Java / .NET / Rust?
S: Ja. Java har com.fasterxml.uuid:java-uuid-generator 5.0+ och JDK 21 har det via bibliotekshjälpare. .NET 9 levererar Guid.CreateVersion7() i BCL. Rust använder uuid-cratens Uuid::now_v7() bakom v7-funktionsflaggan. De flesta andra ekosystem (Elixir, Ruby, PHP, Swift, Kotlin) har också välunderhållna paket — sök efter ”uuidv7” eller ”uuid v7” i språkets paketregister. Wire-formatet är identiskt över alla, så en v7 genererad i Go kan tolkas och få tidsstämpeln extraherad av JavaScript utan någon transformation.
F: Har Node.js en inbyggd UUIDv7-generator?
S: Ja — från och med Node.js v26.1.0 (släppt 2026-05-07) exponerar standardbiblioteket crypto.randomUUIDv7([options]). Importera det som import { randomUUIDv7 } from 'node:crypto' och anropa det utan argument för att få en RFC 9562 v7-UUID-sträng. Det enda alternativet som stöds är disableEntropyCache (boolesk, standard false); som standard cachar Node tillräckligt med slumpmässiga data i förväg för att generera de nästa ~128 UUID:erna, vilket är samma optimering som används av crypto.randomUUID(). Viktig reservation från den officiella dokumentationen: ”den inbäddade tidsstämpeln förlitar sig på en icke-monoton klocka och är inte garanterat strikt ökande”. Med andra ord: två UUID:er genererade i samma millisekund, eller alla UUID:er skapade över ett NTP-steg / VM-klockskev bakåt, sorteras kanske inte i skapelseordning. Om du behöver strikt monotonicitet inom en millisekund, använd en userland-implementering som följer RFC 9562 §6.2 Metod 2 (npm-paketet uuidv7, eller det här verktyget med Monoton-omkopplaren på).
F: Hur lagrar jag UUIDv7 effektivt i en databas?
S: Lagra den som en 16-byte binär typ istället för en 36-tecken lång sträng — du sparar 20 byte per rad, halverar indexstorleken och får en snabbare jämförelseväg. Använd PostgreSQL:s uuid-typ, MySQL BINARY(16), SQL Server uniqueidentifier eller SQLite BLOB. Lägg till en CHECK-begränsning om att versionsnibblet är lika med 7 om du vill framtvinga det. Med v7 klustras raderna naturligt efter skapelsetid, så ett täckande index på (uuid_pk) är vanligtvis tillräckligt — du behöver inte ett separat (created_at)-index för kronologiska frågor.