Encoders & Utilities

Generatore UUID

Genera UUID v1, v4, v7, NIL o MAX in batch. Toggle per maiuscole, parentesi o senza trattini.

Version

v4 — random v7 — time-ordered (RFC 9562) v1 — time + node NIL — all zeros MAX — all ones

Quantity Between 1 and 1000.

UPPERCASE Wrap in {braces} No dashes

When to use which version

v1 — time-based + MAC node. Good when ordering matters and you need debuggable insertion order. Leaks MAC/host info if real MAC is used; we generate a random multicast-bit node so no real hardware is exposed.
v4 — random. Default choice. Collision-resistant (2¹²² entropy), good for distributed systems where ordering doesn't matter. Bad for DB primary keys at scale (random order kills B-tree locality).
v7 — time-ordered (RFC 9562, 2024). 48-bit Unix-ms timestamp prefix → lexicographically sortable + index-friendly. Recommended for new DB primary keys. Use this if you can.
NIL — 00000000-0000-0000-0000-000000000000. Sentinel/placeholder value.
MAX — all-ones UUID (RFC 9562). Useful as "infinity" sentinel paired with NIL.

Informazioni su questo strumento

UUID Generator emette identificatori universalmente unici a 128 bit conformi a RFC 9562 (l'aggiornamento 2024 dell'originale RFC 4122). Sono supportate cinque varianti: v1 (tempo + MAC, prevedibile nel tempo), v4 (casuale — la più comune), v7 (casuale ordinato nel tempo, il moderno default per le chiavi di database), NIL (placeholder tutto-zero) e MAX (tutto-FF — utile come limite "massimo" nelle query a intervallo). Si genera uno o fino a 1000 alla volta.

Tutta la casualità proviene da crypto.getRandomValues() — lo stesso CSPRNG del browser usato da TLS. Gli UUID non si ripetono in pratica: i 122 bit di casualità di v4 danno una probabilità di collisione così bassa che generare un miliardo al secondo per 85 anni ha circa il 50% di probabilità di una singola collisione (il "birthday bound" per 122 bit). v7 riduce la casualità a 74 bit in cambio dell'ordinamento temporale, che è comunque collision-safe a qualsiasi scala realistica.

Quando usare questo strumento

Generare un ID di esempio per test. Più veloce che eseguire il generatore del proprio ORM.
Scegliere la versione giusta. v7 si ordina per tempo quando usato come chiave primaria — molto meglio per gli indici B-tree rispetto a v4. Usare v4 solo quando si vuole attivamente nascondere l'ordine.
Seeding di fixture. 100 UUID distinti con un clic per un set di dati di test.
Ispezione del formato UUID. Validare che una stringa ricevuta sia effettivamente un UUID valido e scoprire quale versione.

Su v7 vs v4

UUID v7 è stato standardizzato nel 2024 specificamente per correggere la casualità anti-database-friendly di v4. v7 ha il timestamp (48 bit, risoluzione al millisecondo) nei bit alti, quindi gli UUID appena generati si ordinano lessicograficamente per tempo di creazione. Questo mantiene un indice B-tree "compatto" (i nuovi inserimenti si raggruppano a un'estremità) anziché disperdersi attraverso le pagine. Per nuove applicazioni, v7 è il nuovo default; v4 rimane utile solo quando si vuole specificamente l'imprevedibilità dell'ordine.

Domande frequenti

Qual è la differenza tra UUID v4 e v7?

v4 è 122 bit di dati casuali — l'ordine di due UUID v4 è privo di significato. v7 incorpora un timestamp Unix in millisecondi a 48 bit nei bit alti, quindi gli UUID v7 generati più tardi si ordinano dopo quelli generati prima. Per chiavi primarie di database, v7 è drasticamente più amichevole con gli indici B-tree; v4 sparge le scritture attraverso l'intero indice e causa più page split.

Gli UUID sono realmente unici?

Effettivamente sì. Per v4, con 122 bit di casualità, occorrerebbe generare circa 2,7 × 10^18 UUID prima di avere una probabilità del 50% di una collisione. Il mondo ne genera trilioni all'anno e le collisioni non sono un vero problema. v7 con 74 bit casuali è ancora sicuro fino a circa 1,5 × 10^11 per millisecondo. L'UUID NIL (00000000-...) è l'unica eccezione ed è riservato.

Perché alcuni UUID hanno delle parentesi attorno?

Una convenzione Microsoft — Windows COM e .NET spesso mostrano i GUID come {xxxxxxxx-xxxx-...}. Le parentesi non fanno parte del valore, sono solo decorative. La maggior parte degli altri ecosistemi (Linux, JSON API, JavaScript) scrive gli UUID senza parentesi. Il nostro toggle permette di produrre entrambi i formati; cambiare al bisogno quando si interopera con stack Windows-heavy.

Posso usarli come chiavi primarie del database?

Sì — gli UUID sono ampiamente usati come PK. Per nuove tabelle, preferire v7 (o ULID, un formato correlato) in modo che l'indice resti compatto. v4 è tecnicamente accettabile ma causa più write amplification sugli indici B-tree a causa della dispersione casuale. PostgreSQL, MySQL 8+ e SQLite hanno tutti supporto UUID nativo o quasi nativo; in MySQL pre-8, archiviare come BINARY(16) per la compattezza.