Générez des UUID v4, UUID v7 (RFC 9562 triable chronologiquement), ULID et NanoID à la volée. Options d'alphabet, taille personnalisée et décodeur intégré affichant version, variant et timestamp. 100 % local (WebCrypto).
UUID v4 est 100 % aléatoire (122 bits d'entropie), ce qui le rend imprédictible mais inefficace comme clé primaire en base de données : les insertions se font partout dans l'index B-tree, causant de la fragmentation. UUID v7 (RFC 9562, publié en 2024) encode d'abord un timestamp Unix en millisecondes (48 bits), puis des bits aléatoires : il reste globalement unique mais se trie chronologiquement, ce qui garde l'index compact. Pour Postgres, MySQL ou SQL Server, UUID v7 est aujourd'hui le choix recommandé.
Les deux encodent un timestamp + du random et sont triables. Le choix dépend de l'écosystème : UUID v7 est standardisé (RFC 9562) et supporté nativement par la plupart des bases et langages ; ULID est plus court (26 vs 36 caractères), URL-safe sans échappement, et utilise l'alphabet Crockford Base32 (évite les caractères ambigus I, L, O, U). Si vous restez dans un stack qui connaît UUID, gardez UUID v7. Pour un id visible dans des URL courtes ou des logs, ULID est plus lisible.
NanoID est un générateur d'id court et personnalisable créé par Andrey Sitnik. Par défaut : 21 caractères dans un alphabet URL-safe de 64 symboles, soit environ 126 bits d'entropie (équivalent à UUID v4). Il est idéal pour des identifiants courts partagés dans des URL (ex. raccourcisseurs, slugs, clés de partage) ou pour des id lisibles avec un alphabet sans ambiguïté. Il n'encode pas de timestamp.
Pour UUID v4 (122 bits aléatoires), la probabilité d'une collision reste négligeable jusqu'à environ 2,7 milliards d'id générés par seconde pendant 100 ans (estimation RFC 4122). Pour NanoID 21 chars URL-safe (126 bits), il faut générer environ 1 milliard d'id par seconde pendant 1000 ans pour avoir 1 % de chance de collision. Pour UUID v7 et ULID, les 74-80 bits aléatoires concatenés au timestamp ms suffisent pour garantir l'unicité à l'échelle d'une application, même avec plusieurs milliers d'insertions par milliseconde.
Oui pour UUID v1 (horloge 100 ns depuis 1582-10-15), UUID v7 (timestamp Unix ms, 48 premiers bits) et ULID (timestamp Unix ms encodé sur les 10 premiers caractères Crockford). C'est impossible pour UUID v4 et NanoID, qui ne contiennent aucune information temporelle. Collez votre identifiant dans le décodeur de la page pour lire automatiquement la date, la version et le variant.
Les générateurs s'appuient sur l'API WebCrypto du navigateur (crypto.getRandomValues), adossée à un PRNG cryptographique (CSPRNG) validé. L'entropie est suffisante pour servir de token d'invitation, d'id de session non deviniable ou de clé de partage temporaire. En revanche, un UUID ou un ULID n'est PAS un secret à longue durée : préférez un token opaque signé (JWT, Paseto) ou une clé API dédiée pour l'authentification.