Genera UUID v4 (Universally Unique Identifier) singoli o in bulk. Formato standard, maiuscolo, minuscolo o senza trattini.
Seleziona la versione UUID desiderata, il numero di UUID da generare (da 1 a 100) e il formato dell'output. Clicca Genera e copia il risultato con un click. La generazione avviene nel browser usando crypto.randomUUID() o algoritmi equivalenti crittograficamente sicuri — nessun dato viene inviato a server. Gli UUID generati sono pronti da usare come primary key, identificatori di sessione, nomi di file univoci o in qualsiasi contesto che richieda un ID non prevedibile.
UUID v1 (time-based): incorpora timestamp e MAC address della macchina. Ordinabile per tempo di creazione, ma espone informazioni sull'hardware — sconsigliato per use case pubblici. UUID v4 (random): 122 bit di casualità crittografica. Lo standard de-facto per la maggior parte delle applicazioni moderne — semplice, universalmente supportato, nessuna dipendenza dall'hardware. UUID v7 (time-ordered random): introdotto nel 2022, combina un timestamp a 48 bit con 74 bit casuali. Ordinabile cronologicamente come v1, ma senza esporre l'hardware — la scelta migliore per primary key in database con indici B-tree.
UUID è lo standard universale: supportato nativamente da PostgreSQL, MySQL, MongoDB, tutti gli ORM principali e ogni linguaggio di programmazione. ULID (Universally Unique Lexicographically Sortable Identifier) è ordinabile lessicograficamente, più compatto (26 caratteri uppercase) e URL-safe — ma non è standardizzato nello stesso modo. NanoID è ancora più corto e completamente personalizzabile nell'alfabeto, ideale per URL shortener e slug. Scegli UUID v4 come default; UUID v7 o ULID se hai bisogno di ordinamento temporale; NanoID solo se hai vincoli di lunghezza.
PostgreSQL ha un tipo nativo UUID che occupa 16 byte — più efficiente della stringa. MySQL supporta UUID ma non ha un tipo dedicato: si usa BINARY(16) o VARCHAR(36). MongoDB usa ObjectId (simile a UUID v1) come default ma accetta UUID nativamente. Per primary key su tabelle con molti insert, UUID v4 casuale causa frammentazione degli indici B-tree perché gli UUID non sono sequenziali — UUID v7 o ULID risolvono questo problema mantenendo l'inserimento ordinato.
Statisticamente sì. La probabilità di generare due UUID v4 identici è 1 su 5,3×10³⁶. Per contestualizzare: dovresti generare circa 2,7 miliardi di miliardi di UUID prima di avere il 50% di probabilità di una collisione. In qualsiasi applicazione reale è considerato impossibile.
Sì, è uno dei casi d'uso più comuni. Per database con molti insert considera UUID v7 invece di v4: essendo ordinabili per tempo di creazione, mantengono la località delle pagine negli indici B-tree con performance di insert significativamente migliori su tabelle grandi (milioni di righe).
In JavaScript/Node.js moderno: crypto.randomUUID() (nativo, nessuna dipendenza). In Python: import uuid; uuid.uuid4(). In Java: UUID.randomUUID(). In PHP con Laravel: Str::uuid(). In Go: libreria github.com/google/uuid. Tutte le implementazioni sopra usano entropia crittograficamente sicura.
Semanticamente no: a1b2c3d4-... e A1B2C3D4-... sono lo stesso UUID. La convenzione più comune è lowercase. PostgreSQL con tipo UUID nativo li normalizza automaticamente. Sii comunque consistente: scegli una convenzione e rispettala in tutta l'applicazione per evitare bug nei confronti di stringhe.
UUID nil (00000000-0000-0000-0000-000000000000) è il valore "zero" — tutti i bit a 0. Usato come valore sentinella o per indicare "nessun ID". UUID max (ffffffff-ffff-ffff-ffff-ffffffffffff) è il contrario — tutti i bit a 1. Entrambi sono UUID validi per convenzione ma non devono essere usati come identificatori reali nei database.