Générateur d'UUID, ULID et Nano ID
Générez en masse des UUID v4, des UUID v7 ordonnés dans le temps, des ULID et des Nano ID, et lisez la version et le timestamp contenus dans un identifiant.
Épinglez vos outils ici. Ils sont enregistrés dans ce navigateur.
Épinglez un outil et son autocollant arrive ici.
Générez en masse des UUID v4, des UUID v7 ordonnés dans le temps, des ULID et des Nano ID, et lisez la version et le timestamp contenus dans un identifiant.
Un UUID version 4 se compose de 122 bits aléatoires. Il ne dit rien du moment ni du lieu de sa création, et c'est le choix habituel quand un identifiant doit seulement être unique. L'UUID version 7, normalisé par la RFC 9562 en 2024, place un timestamp Unix de 48 bits en millisecondes devant 74 bits aléatoires. Les nouveaux identifiants se trient après les anciens, si bien que des lignes insérées ensemble restent groupées dans un index de base de données, au prix de révéler la date de création à quiconque voit l'identifiant.
Un ULID reprend la même idée sous une autre forme : 48 bits de temps et 80 bits aléatoires, en 26 caractères en Base32 de Crockford, insensibles à la casse et sans tirets. Un Nano ID est une chaîne aléatoire dont vous choisissez la longueur et l'alphabet. Le réglage par défaut, 21 caractères parmi 64 symboles compatibles avec les URL, apporte 126 bits, un peu plus qu'un UUID version 4, dans une chaîne plus courte.
Des identifiants aléatoires peuvent en théorie entrer en collision. Pour la version 4, il faudrait générer environ 2,7 trillions (2,7 × 10^18) d'UUID avant que la probabilité d'un seul doublon atteigne une chance sur deux : c'est pourquoi les applications les considèrent comme uniques. Un Nano ID plus court ou un petit alphabet réduit cette marge : la ligne sous les options indique combien de bits aléatoires vous apporte votre choix.
Un identifiant n'est pas un secret. Les versions 1, 6 et 7 et les ULID révèlent leur date de création, et la RFC 9562 déconseille de se fier à un UUID comme preuve d'autorisation. Pour un lien de réinitialisation de mot de passe, une session ou une clé d'API, utilisez un token aléatoire d'au moins 128 bits et ne conservez sur le serveur que son hachage.
Dans la forme habituelle xxxxxxxx-xxxx-Vxxx-Nxxx-xxxxxxxxxxxx, le chiffre V est la version et les premiers bits de N sont la variante : 8, 9, a ou b pour la structure RFC 9562 qu'utilisent presque tous les UUID. Les versions 1 et 6 contiennent un compteur de 60 bits de pas de 100 nanosecondes depuis le 15 octobre 1582, accompagné d'un identifiant de nœud, qui était à l'origine l'adresse MAC de la carte réseau. La version 7 contient des millisecondes Unix. Les versions 3 et 5 sont des hachages d'un nom et la version 4 est aléatoire : elles ne contiennent rien à décoder.
Les dix premiers caractères d'un ULID sont son timestamp. L'analyseur accepte aussi les UUID sans tirets, entre accolades ou avec le préfixe urn:uuid:.
Chaque bit aléatoire provient de crypto.getRandomValues, le générateur de nombres aléatoires cryptographique du navigateur. Rien n'est demandé à un serveur et rien n'est conservé.
Les UUID version 7 générés dans la même milliseconde gardent le timestamp et ajoutent un incrément aléatoire aux 74 bits aléatoires, selon la méthode monotone décrite dans la RFC 9562 : un lot se trie donc toujours dans l'ordre de génération. Les ULID générés dans la même milliseconde ajoutent un à leur partie aléatoire, comme le décrit la spécification ULID. Cet ordre vaut pour les identifiants de cette page. Des identifiants générés sur des machines différentes dans la même milliseconde se trient dans un ordre quelconque. Les caractères des Nano ID sont choisis en écartant les octets aléatoires qui tombent hors de l'alphabet, si bien que chaque symbole a la même probabilité.
La version 7 convient mieux à une clé primaire quand vous voulez que les nouvelles lignes se placent les unes à côté des autres dans l'index et que cela ne vous gêne pas que l'identifiant révèle sa date de création. La version 4 s'impose quand l'identifiant ne doit rien révéler. Les deux font 128 bits et tiennent dans la même colonne uuid.
C'est possible, mais bien trop improbable pour qu'on s'en préoccupe. Un UUID version 4 a 122 bits aléatoires : il en faut environ 2,7 trillions (2,7 × 10^18) avant qu'un seul doublon devienne aussi probable qu'improbable. Le vrai risque est une source d'aléa faible, c'est pourquoi cet outil utilise le générateur cryptographique du navigateur.
Non, mais les deux se ressemblent. Tous deux font 128 bits et commencent par un timestamp de 48 bits en millisecondes : les bits d'un ULID tiennent donc dans une colonne UUID de 128 bits. Un ULID n'a pas de champs de version ni de variante, la RFC 9562 ne le définit donc pas comme un UUID, et sa forme textuelle utilise le Base32 de Crockford là où un UUID utilise l'hexadécimal.
Oui pour les UUID versions 1, 6 et 7 et pour les ULID, qui contiennent un timestamp. Collez la valeur dans l'analyseur pour la voir sous forme de date. Un UUID version 4 est aléatoire et ne contient aucune date.
Elle s'ouvre dans sa propre fenêtre et continue de fonctionner hors ligne.
Pour l'installer, touchez le bouton Partager, puis « Sur l'écran d'accueil ».