UUID, ULID, Nanoid : quel identifiant unique choisir en 2026 ?

UUID v4 aléatoire, UUID v7 et ULID triables par date, Nanoid compact : comparatif et générateurs en ligne pour clés primaires et IDs publics.

23.09.2026

13 min de lecture

Partager cet article:

uuidulidnanoididentifiersdatabasetools-dev

Un identifiant aléatoire, triable ou compact répond à trois besoins différents

Un identifiant auto-incrémenté révèle le nombre de lignes d'une table. Il se coordonne mal entre plusieurs serveurs qui écrivent en même temps, et il se devine (l'ID 1042 laisse supposer qu'un ID 1041 existe). D'où l'intérêt d'un identifiant créé côté client ou côté serveur, sans compteur central. Mais « unique et imprévisible » ne veut pas dire la même chose d'un format à l'autre. Le générateur UUID produit un UUID v4 aléatoire, un UUID v7 qui commence par un horodatage, ou l'UUID nil pour les tests. Le générateur ULID poursuit le même but que l'UUID v7, un identifiant triable par date de création, dans une chaîne Base32 plus courte. Le générateur Nanoid se passe d'horodatage : tous ses caractères sont aléatoires, d'où une chaîne plus courte à entropie égale. Les trois tournent dans le navigateur. Ils sont regroupés sur le hub des outils utilitaires pour développeurs, avec le testeur de regex et le générateur de mot de passe.

UUID : v4, v7 ou nil, avec ou sans tirets, en minuscules ou en majuscules, format simple, accolades ou URN, de 1 à 50 ID par liste

ULID : 26 caractères Crockford Base32, majuscules par défaut, option Monotone qui garde une liste en ordre croissant, horodatage décodé sous chaque ID

Nanoid : toute taille de 2 à 64 (21 par défaut, cinq tailles prédéfinies), alphabet URL-safe, alphanumérique, numérique, sans homoglyphes ou personnalisé, entropie affichée en bits

Les trois outils génèrent via l'API Web Crypto du navigateur, sans envoi de données ; sans crypto.getRandomValues, ULID et Nanoid affichent une erreur plutôt qu'un identifiant faible

Pas de bouton Générer : la liste est générée à nouveau à chaque changement d'option, avec Tout copier, le téléchargement .txt et un bouton de copie par ligne

Choisir le bon outil selon le contexte

Bons usages du générateur en ligne

Prototypage, tests et vérifications visuelles avant d'écrire la moindre ligne de code serveur.

Prototyper un schéma de base de données et comparer immédiatement des clés v7 face à des clés v4

Produire des jeux de test ou des fixtures, de 10 à 50 ID à la fois, copiés ou téléchargés en .txt

Vérifier que l'option Monotone du générateur ULID garde une liste en ordre croissant avant de compter sur le même comportement côté serveur

Recalculer l'entropie réelle d'un Nanoid personnalisé (alphabet, taille) avant de la figer dans une spécification d'API

Illustrer une discussion d'équipe sur triable vs aléatoire sans écrire une ligne de code

Ce qui doit rester côté serveur ou dans une bibliothèque

Le générateur en ligne prototype le format ; il ne remplace pas la génération en production.

Génération d'ID à fort débit en production : une bibliothèque serveur (uuid, ulid, nanoid sous Node) évite tout passage par le navigateur

Jetons de sécurité (réinitialisation de mot de passe, session, invitation) : un secret dédié, jamais un identifiant public réutilisé

Contrôle d'autorisation sur une ressource : un identifiant imprévisible ne remplace jamais une vérification de propriété côté serveur

Migration d'une clé auto-incrémentée vers UUID ou ULID en production : planifiez la double écriture et le nouvel index avant de couper l'ancien compteur

Les pièges qui coûtent cher une fois en production

Utiliser un UUID v4 aléatoire comme clé primaire indexée

Une clé primaire remplie d'UUID v4 insère chaque nouvelle ligne à une place aléatoire de l'index en arbre B. Sur une table très sollicitée, les pages se fragmentent et les écritures ralentissent. La cause est le tirage purement aléatoire, pas l'UUID en soi. Un UUID v7 (RFC 9562) place un horodatage en millisecondes dans ses 48 premiers bits et complète par des bits aléatoires. Un ULID applique la même idée en Base32. Les nouvelles valeurs arrivent alors en fin d'index, comme avec une clé auto-incrémentée, sans révéler de compteur exploitable. La RFC 9562 note que l'écart peut atteindre un ordre de grandeur, voire plus. Le générateur UUID passe de v4 à v7 sans changer la forme du champ (36 caractères avec tirets). Le générateur ULID propose la variante plus courte, en 26 caractères.

Choisir « v4 » par réflexe pour une clé primaire à fort volume d'écritures, puis découvrir la fragmentation de l'index en production

Croire qu'un UUID « aléatoire » est plus sûr qu'un UUID « triable », alors qu'un v7 garde 74 bits aléatoires et un ULID 80

Mélanger v4 et v7 dans la même colonne en supposant qu'ils se trient par date

Ne jamais vérifier si le SGBD ou l'ORM utilisé recommande déjà un identifiant triable pour les clés indexées

Gardez v4 pour un identifiant purement opaque (session, nonce, jeton). Passez à v7 ou ULID dès que la table reçoit des écritures en continu et que l'ordre d'insertion compte pour les performances de l'index.

Croire qu'un identifiant imprévisible remplace un contrôle d'autorisation

Remplacer une clé auto-incrémentée par un UUID, un ULID ou un Nanoid empêche l'énumération simple (essayer ?id=124, puis 125…). Il ne remplace pas pour autant un contrôle d'autorisation. Un identifiant obtenu ailleurs (lien partagé, ligne de journal, en-tête Referer) reste lisible si l'API ne vérifie pas à qui appartient la ressource. Un ULID pose un problème de plus. Ses 10 premiers caractères donnent la date de création en clair. Pour une clé primaire, c'est sans conséquence. Pour un jeton censé rester opaque, c'est un défaut : qui connaît à peu près la date de création réduit l'espace à explorer avant même d'attaquer la partie aléatoire.

Retirer une vérification côté serveur en pensant qu'un identifiant « difficile à deviner » suffit à protéger une route

Utiliser un ULID comme jeton de réinitialisation de mot de passe ou lien d'invitation, en le croyant aussi opaque qu'un secret dédié

Publier des ULID dans des URL publiques sans réaliser qu'ils révèlent la date de création de la ressource

Compter sur un ordre monotone d'une liste à l'autre ou entre processus, alors que l'option Monotone ne couvre que les ID d'une même liste

UUID, ULID et Nanoid remplacent un compteur, pas une session ni un secret. Pour un jeton à durée de vie courte, générez une valeur dédiée et vérifiez toujours l'autorisation côté serveur.

Réduire l'alphabet ou la taille d'un Nanoid sans recalculer l'entropie

La résistance aux collisions d'un Nanoid dépend à la fois de la taille et de l'alphabet. Le réglage par défaut de l'outil, 21 caractères tirés de l'alphabet URL-safe de 64 symboles, porte 126 bits aléatoires, contre 122 pour un UUID v4. Tout autre réglage change ce calcul. À 8 caractères sur le même alphabet, le risque d'au moins une collision atteint 1 % vers 2,4 millions d'identifiants. L'alphabet Numérique (10 symboles) réduit lui aussi l'espace : 21 chiffres donnent environ 70 bits. Rien ne vous prévient, sauf l'entropie en bits affichée par le bouton d'information à côté du champ Taille.

Passer à l'alphabet Numérique pour un identifiant qui doit rester unique à grande échelle, sans revérifier l'entropie affichée

Descendre à 6 ou 8 caractères pour un slug « plus court » sans estimer combien d'identifiants seront vraiment créés

Coller un alphabet personnalisé avec des caractères répétés en comptant sur sa longueur, alors que l'outil retire les doublons avant de calculer l'entropie

Confondre l'alphabet « Sans homoglyphes » (pensé pour un code lu à voix haute) avec un alphabet pensé pour la densité d'information

Un Nanoid raccourci sans nouveau calcul de l'entropie peut fonctionner en test, puis produire des collisions en production, une fois le volume réel atteint.

Mélanger les variantes de format dans le même jeu de données

Le sélecteur de format de l'outil UUID (simple, accolades, URN) et l'interrupteur des majuscules changent l'écriture, pas les 128 bits sous-jacents. Une colonne qui compare des chaînes brutes ne sait pas que {550e8400-…} et urn:uuid:550e8400-… désignent le même UUID, sauf normalisation préalable. Même piège côté ULID. Le Crockford Base32 ignore la casse au décodage, mais une contrainte UNIQUE sur une colonne de texte en tient souvent compte, comme PostgreSQL par défaut.

Générer des UUID au format urn:uuid: pour un export, puis les comparer tels quels à des UUID nus déjà stockés en base

Activer les accolades pour un test manuel et oublier de les retirer avant l'import

Stocker des ULID en majuscules quand ils viennent du client et en minuscules quand le serveur les recalcule

Ne pas normaliser casse et tirets avant un test d'égalité ou une contrainte UNIQUE

Choisissez un seul format d'écriture au moment du stockage (en général minuscules, avec tirets, sans préfixe), et normalisez toute valeur externe avant de comparer.

Format, taille et tri des quatre variantes

UUID v4, UUID v7, ULID, Nanoid

Un même objectif, l'unicité sans coordinateur central, sous quatre formes différentes.

UUID v4 (RFC 9562) : 128 bits dont 122 aléatoires, 36 caractères avec tirets, comme 550e8400-e29b-41d4-a716-446655440000, où le 4 qui ouvre le troisième groupe indique la version. Il ne se trie pas par date de création. C'est le format le plus répandu, avec un type dédié dans PostgreSQL et MariaDB.

UUID v7 : même forme à 36 caractères, mais les 48 premiers bits portent un horodatage en millisecondes et le chiffre de version vaut 7. Il se trie par date, même sous forme de texte, et reste un UUID standard, avec 74 bits aléatoires.

ULID : 26 caractères en Crockford Base32 (ex. 01HXYZ0123456789ABCDEFGHJK), 48 bits de temps puis 80 bits aléatoires. Même logique de tri que l'UUID v7, écriture plus courte, insensible à la casse au décodage.

Nanoid : longueur de 2 à 64 caractères (21 par défaut) et alphabet au choix. Sans horodatage intégré, un Nanoid ne se trie pas par date de création. C'est le plus compact des quatre à entropie comparable.

Ce que proposent réellement les générateurs FastMinify

Les options exposées par chaque outil, telles qu'elles existent aujourd'hui.

uuid-generator : version v4, v7 ou nil, tirets et majuscules activables, format simple, accolades ou URN, de 1 à 50 ID par liste. URN impose les tirets et les minuscules, et nil donne toujours un seul ID. Chaque ligne v7 affiche son horodatage.

ulid-generator : majuscules par défaut, option Monotone, horodatage décodé sous chaque ID, de 1 à 50 par liste. Tous les ID d'une liste partagent la même milliseconde. Monotone ajoute un à la partie aléatoire précédente au lieu d'en tirer une nouvelle.

nanoid-generator : taille de 2 à 64 (tailles prédéfinies 8, 12, 16, 21 et 32), entropie en bits, de 1 à 50 par liste. L'alphabet est URL-safe par défaut, sinon alphanumérique, numérique, sans homoglyphes ou personnalisé. Un alphabet personnalisé accepte jusqu'à 256 caractères, sans les doublons.

Les trois tournent dans le navigateur via Web Crypto et n'envoient rien. ULID et Nanoid n'ont pas de solution de repli moins sûre : sans crypto.getRandomValues, ils affichent une erreur au lieu d'une liste. Le générateur UUID, lui, se replie alors sur Math.random.

Quand l'ordre de tri change vraiment la donne

Trois situations concrètes où le choix du format a un impact mesurable.

Table à fort volume d'écritures avec clé primaire indexée : un v4 disperse les insertions dans l'index. Un v7 ou un ULID s'ajoute en fin d'index, comme une clé auto-incrémentée, sans exposer de compteur.

Tri « derniers créés en premier » sans colonne created_at dédiée : possible directement sur l'ID pour v7 et ULID (tri lexicographique = tri chronologique), impossible sur v4 ou Nanoid.

Synchronisation entre systèmes distribués sans coordinateur central : les quatre formats gardent des identifiants uniques en pratique sans serveur central, ce qu'une clé auto-incrémentée ne sait pas faire.

URL publique la plus courte à budget d'entropie comparable : un Nanoid à 21 caractères (défaut) bat les 36 caractères d'un UUID et les 26 d'un ULID.

Générer, ajuster, copier

Régler les générateurs UUID et ULID

Sur le générateur UUID, la liste est générée à nouveau dès que vous changez une option : il n'y a pas de bouton Générer. Sur le générateur ULID, l'horodatage décodé de chaque ID apparaît juste sous sa ligne.

1. Choisir la version ou l'option Monotone

Côté UUID, v4 donne un tirage purement aléatoire, v7 un ordre par date et nil l'UUID tout à zéro, avec une quantité fixée à 1. Les v7 d'une même liste partagent en général la même milliseconde et ne sont donc pas triés entre eux. Côté ULID, tous les ID d'une liste partagent la même milliseconde et sortent dans un ordre aléatoire. Activez Monotone pour obtenir un ordre strictement croissant.

2. Ajuster tirets, casse et format

Côté UUID, le format URN impose tirets et minuscules et désactive les deux interrupteurs. Côté ULID, les majuscules sont actives par défaut ; le décodage Crockford Base32 donne le même résultat en minuscules.

3. Régler la quantité (1 à 50) puis copier

Copiez toute la liste d'un coup, téléchargez un fichier .txt ou copiez une seule ligne avec le bouton placé sur chaque ID.

Régler la taille et l'alphabet du Nanoid avant de copier

Le générateur Nanoid affiche l'entropie en bits dans l'infobulle du bouton d'information placé à côté de Taille. La valeur suit chaque changement de taille ou d'alphabet : inutile de la calculer de tête.

Taille : de 2 à 64 caractères, par le curseur, le champ numérique ou les tailles prédéfinies 8 / 12 / 16 / 21 / 32

Alphabet : URL-safe par défaut, sans + / = à encoder dans une URL, puis alphanumérique, numérique, sans homoglyphes (sans 0, O, o, I, l ni 1) ou personnalisé jusqu'à 256 caractères

Un alphabet personnalisé perd ses doublons et doit garder au moins 2 caractères différents

De 1 à 50 ID par liste, Tout copier, le téléchargement .txt ou un bouton de copie sur chaque ligne

Aucun repli si le navigateur ne fournit pas crypto.getRandomValues : un message d'erreur remplace la liste plutôt qu'un identifiant moins aléatoire

Les mêmes formats côté serveur, en Node

UUID v4 et v7 en Node

Node fournit crypto.randomUUID() pour un UUID v4, sans dépendance. Depuis Node 24.16 et 26.1, crypto.randomUUIDv7() produit aussi un v7. Sur les versions plus anciennes, le petit paquet uuid se charge de la variante triable, comme dans cet exemple.

Exemple de base

const crypto = require('node:crypto')

// v4 — intégré à Node, aucune dépendance
const id = crypto.randomUUID()

// v7 — crypto.randomUUID() de Node ne génère que du v4
const { v7: uuidv7 } = require('uuid')
const sortableId = uuidv7()

ULID en Node

Node n'a pas d'implémentation ULID native. Le paquet ulid génère des ULID et décode leur horodatage intégré.

Exemple de base

const { ulid, decodeTime } = require('ulid')

const id = ulid() // 26 caractères, majuscules
const createdAtMs = decodeTime(id)

Nanoid en Node

Le paquet nanoid utilise le même alphabet URL-safe et la même taille par défaut que l'outil (21 caractères). Sa fonction customAlphabet accepte un alphabet et une taille sur mesure.

Exemple de base

const { nanoid, customAlphabet } = require('nanoid')

const id = nanoid() // 21 caractères, alphabet url par défaut
const numericId = customAlphabet('0123456789', 12)()

FastMinify uuid-generator / ulid-generator / nanoid-generator

Pas d'installation, rien d'envoyé, jusqu'à 50 ID par liste et toutes les options de format des trois outils. En contrepartie, pas de génération à fort débit dans le navigateur ni d'ordre monotone d'une liste à l'autre ou entre onglets. Un alphabet Nanoid personnalisé est limité à 256 caractères. Servez-vous des pages pour prototyper un schéma ou produire des fixtures, et gardez uuid, ulid et nanoid côté serveur pour la production.

Conclusion

Aucun identifiant ne convient à tous les cas. UUID v4 reste le bon choix pour un identifiant purement opaque, sans contrainte de tri, avec le support natif le plus large. UUID v7 ou ULID prennent le relais dès que l'ordre d'insertion compte pour les performances d'un index ou pour un tri sans colonne created_at dédiée. Nanoid donne la chaîne la plus courte à entropie donnée, ce qui sert dans une URL. Aucun des trois ne remplace un contrôle d'autorisation côté serveur. Aucun n'est fait non plus pour une génération à fort débit dans le navigateur : c'est le rôle des bibliothèques serveur uuid, ulid et nanoid. Si ces identifiants transitent dans une charge JSON d'API, le guide sur l'optimisation d'une API REST JSON prolonge cette lecture. Le validateur de schéma JSON vérifie ensuite le format attendu d'un champ id.

Générer un identifiant dans le navigateur

Générateur UUID Générateur ULID Générateur Nanoid Hub Outils utilitaires

UUID v4 pour un identifiant purement opaque, sans contrainte de tri

UUID v7 ou ULID dès que l'ordre d'insertion compte pour l'index ou pour un tri applicatif

Nanoid pour la chaîne la plus courte possible à budget d'entropie donné, notamment dans une URL

Aucun des trois ne remplace un contrôle d'autorisation côté serveur

Génération à fort débit en production : une bibliothèque serveur (uuid, ulid, nanoid), pas le générateur du navigateur

Partager cet article

Partager cet article:

Articles connexes

Vérifier une signature JWT contre un JWKS sans backend

Collez un token et un JWKS pour vérifier une signature RS256, ES256 ou HS256 dans le navigateur. Choix par kid, erreurs mesurées, claims à contrôler.

26.10.202614 min de lecture

HTTP/2, HTTP/3 et minification : la minification est-elle encore utile ?

HTTP/2 et HTTP/3 changent le trajet des fichiers, pas leur poids. Mesures de taille, de compilation et de bundling : ce que la minification apporte encore.

22.10.202617 min de lecture

Timestamp Unix : convertir un epoch et éviter les erreurs de fuseau

Convertissez un epoch Unix en date lisible et inversement, distinguez secondes et millisecondes, et évitez les pièges de fuseau, de JWT et de changement d’heure.

19.10.202620 min de lecture