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

Un identifiant aléatoire, triable ou compact : trois besoins différents

Un simple auto-increment expose le volume de lignes d'une table, se coordonne mal entre plusieurs serveurs qui écrivent en même temps, et se devine (l'ID 1042 laisse supposer qu'il existe un ID 1041). D'où l'intérêt d'un identifiant généré côté client ou côté serveur sans compteur central. Mais « unique et imprévisible » ne veut pas dire la même chose selon le format choisi. Le générateur UUID produit un UUID v4 purement aléatoire, un UUID v7 dont les premiers bits encodent un horodatage (donc triable), ou le UUID nil de test. Le générateur ULID vise le même objectif que l'UUID v7 — un identifiant triable par date de création — avec une écriture plus courte en Base32. Le générateur Nanoid abandonne l'horodatage intégré pour optimiser la longueur de la chaîne à budget d'entropie donné. Les trois tournent entièrement dans le navigateur et sont regroupés sur le hub des outils utilitaires pour développeurs, à côté du testeur de regex et du générateur de mot de passe.

UUID : versions v4 (aléatoire), v7 (triable, horodatage 48 bits) ou nil ; tirets, majuscules et format (brut, accolades, urn:uuid:) réglables ; 1 à 50 ID par lot

ULID : 26 caractères en Crockford Base32, majuscules par défaut, mode monotone pour un ordre garanti dans le même lot, horodatage décodé affiché sous chaque ID

Nanoid : taille ajustable de 2 à 64 caractères (défaut 21, préréglages 8/12/16/21/32), alphabet url / alphanumérique / numérique / sans caractères ambigus / personnalisé jusqu'à 256 caractères, entropie affichée en direct

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 se met à jour instantanément à chaque changement d'option, avec copie totale, téléchargement .txt ou copie ligne 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 — 10 à 50 ID d'un coup, copiés ou téléchargés en .txt

Vérifier visuellement que le mode monotone du générateur ULID garde bien un ordre croissant au sein d'un même lot avant de l'implémenter 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 côté Node) évite tout aller-retour 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'un auto-increment existant 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 alimentée par des UUID v4 insère chaque nouvelle ligne à une position aléatoire dans l'index B-tree, ce qui fragmente les pages et ralentit les écritures sur une table à fort volume. Ce n'est pas un problème d'UUID en général, c'est un problème d'aléatoire pur : un UUID v7 (RFC 9562) encode un horodatage en millisecondes sur les 48 premiers bits puis complète en aléatoire, et un ULID fait la même chose en Base32. Les deux s'insèrent en fin d'index, comme un auto-increment, sans révéler de compteur exploitable. 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 l'alternative 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 forcément plus sûr qu'un UUID « triable » — la partie aléatoire d'un v7 ou d'un ULID reste large (74 à 80 bits), seul l'ordre d'insertion change

Mélanger v4 et v7 dans la même colonne en supposant qu'ils se comparent chronologiquement entre eux

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 est écrite 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 un auto-increment par un UUID, un ULID ou un Nanoid empêche l'énumération triviale (essayer ?id=124, puis 125…) mais ne vérifie l'autorisation de personne : un identifiant obtenu par un autre canal (lien partagé, log, en-tête referrer) reste lisible si l'API ne contrôle pas la propriété de la ressource. Un ULID pose un problème supplémentaire : ses 10 premiers caractères encodent en clair l'horodatage de création. Ce n'est pas gênant pour une clé primaire, mais c'en est un pour un jeton censé rester opaque — quiconque connaît approximativement la date de création réduit d'autant 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

Ne jamais tester le mode monotone du générateur ULID avant de l'utiliser côté serveur pour garantir un ordre au sein d'une même milliseconde

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 entièrement du produit taille × alphabet. Le réglage par défaut de l'outil (21 caractères sur l'alphabet url à 64 symboles) vise une probabilité de collision comparable à celle d'un UUID v4 pour un rythme de génération réaliste — mais chaque préréglage modifie ce calcul. Passer sur l'alphabet « numeric » (10 symboles) ou descendre à une taille de 6-8 caractères pour un slug plus court peut réduire l'espace d'identifiants de plusieurs ordres de grandeur sans que rien ne le signale, sauf le compteur d'entropie affiché en direct à côté du champ taille.

Passer sur l'alphabet « numeric » pour un identifiant qui doit rester unique à grande échelle, sans revérifier l'entropie affichée

Descendre à 6-8 caractères pour un slug « plus court » sans estimer le rythme de génération réel

Copier un alphabet personnalisé contenant des caractères en double en pensant obtenir la longueur affichée — les doublons sont automatiquement dédupliqués

Confondre l'alphabet « sans caractères ambigus » (pensé pour un code lu à voix haute) avec un alphabet pensé pour la densité d'information

Un Nanoid raccourci sans recalcul de l'entropie peut sembler 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 (brut, accolades, urn:uuid:) et l'interrupteur de casse changent la représentation textuelle, pas les 128 bits sous-jacents — mais une colonne qui compare des chaînes brutes ne sait pas que {550e8400-…} et urn:uuid:550e8400-… désignent le même UUID sans normalisation préalable. Même logique côté ULID : le Crockford Base32 est défini comme insensible à la casse au décodage, mais une contrainte UNIQUE sur une chaîne, elle, est sensible à la casse.

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 tantôt en majuscule (généré côté client), tantôt en minuscule (recalculé côté serveur)

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

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

Format, taille, tri : ce qui distingue vraiment les quatre variantes

UUID v4, UUID v7, ULID, Nanoid

Même objectif — l'unicité sans coordinateur central — quatre formats différents.

UUID v4 : 128 bits dont 122 aléatoires, 36 caractères avec tirets (ex. 550e8400-e29b-41d4-a716-446655440000). Non triable par date de création. Le plus répandu, supporté nativement par la quasi-totalité des bases de données (RFC 9562).

UUID v7 : même forme à 36 caractères, mais les 48 premiers bits encodent l'horodatage en millisecondes — triable lexicographiquement comme chronologiquement, tout en restant un UUID standard.

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 ajustable de 2 à 64 caractères (défaut 21), alphabet ajustable. Aucun horodatage intégré — un Nanoid ne se trie pas par date de création. Le plus compact des quatre à budget d'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 : versions v4 / v7 / nil, tirets on/off, majuscules on/off, format brut / accolades / urn:uuid: (le format urn fige automatiquement tirets et casse), 1 à 50 ID par lot (forcé à 1 pour nil).

ulid-generator : majuscules par défaut, mode monotone (incrémente la partie aléatoire au lieu d'en tirer une nouvelle dans le même lot), horodatage décodé affiché sous chaque ID généré, 1 à 50 par lot.

nanoid-generator : taille 2-64 avec préréglages 8/12/16/21/32, alphabet url (défaut) / alphanumérique / numérique / sans caractères ambigus / personnalisé (jusqu'à 256 caractères, dédupliqué automatiquement), entropie affichée en direct, 1 à 50 par lot.

Les trois tournent entièrement dans le navigateur via Web Crypto, sans envoi de données ; ULID et Nanoid n'ont pas de repli non sécurisé — sans crypto.getRandomValues, l'outil affiche une erreur plutôt qu'un identifiant faible.

Quand la triabilité 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 fragmente l'index par insertions aléatoires ; un v7 ou un ULID s'insèrent en fin d'index, comme un auto-increment, 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 garantissent l'unicité sans serveur central — c'est justement ce qu'un auto-increment 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

UUID et ULID : choisir la version puis ajuster le format

Sur le générateur UUID, la liste se met à jour dès que vous changez une option — il n'y a pas de bouton « générer » séparé. Sur le générateur ULID, l'horodatage décodé de chaque ID apparaît directement sous la ligne générée.

Étape 1 — Choisir la version ou l'option de tri

UUID : v4 pour de l'aléatoire pur, v7 pour du triable, nil pour l'UUID zéro de test (le compteur est alors forcé à 1). ULID : activez le mode monotone si vous générez plusieurs ID dans la même milliseconde et voulez un ordre garanti.

Étape 2 — Ajuster tirets, casse et format

Sur UUID, choisir le format urn:uuid: fige automatiquement les tirets et désactive l'interrupteur de casse. Sur ULID, les majuscules sont activées par défaut ; le décodage Crockford Base32 reste correct même en minuscule.

Étape 3 — Régler le nombre d'ID (1 à 50) puis copier

Copiez toute la liste d'un coup, téléchargez-la en .txt, ou copiez une ligne à la fois avec le bouton dédié à chaque ID.

Nanoid : régler taille et alphabet avant de copier

Le générateur Nanoid affiche l'entropie en bits en direct dès que vous changez la taille ou l'alphabet, pour ne pas avoir à la recalculer de tête.

Taille : 2 à 64 caractères, préréglages rapides 8 / 12 / 16 / 21 / 32

Alphabet : url (défaut, sans + / = pour rester utilisable tel quel dans une URL), alphanumérique, numérique, sans caractères ambigus (0/O et 1/l/I exclus), ou personnalisé jusqu'à 256 caractères

Un alphabet personnalisé est automatiquement dédupliqué et doit contenir au moins 2 caractères distincts pour générer

1 à 50 ID par lot, copie totale, téléchargement .txt, ou copie ligne par ligne

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

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

UUID v4 et v7 en Node

Node expose crypto.randomUUID() nativement pour un UUID v4, sans dépendance. Le module crypto intégré ne génère pas de v7 : il faut passer par un petit paquet npm comme uuid pour la variante triable.

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 expose la génération et le décodage de l'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 reproduit l'alphabet url et la taille par défaut de l'outil (21 caractères), avec customAlphabet pour un alphabet ou 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, pas d'envoi de données, jusqu'à 50 ID par lot, options de format complètes pour les trois formats. Contrepartie : pas de génération à fort débit côté navigateur, pas de garantie de monotonie entre plusieurs onglets ou processus, et un alphabet Nanoid personnalisé plafonné à 256 caractères. Utilisez les pages pour prototyper un schéma ou produire des fixtures ; gardez uuid, ulid et nanoid côté serveur pour la production.

Conclusion

Il n'y a pas un identifiant « meilleur » dans l'absolu. 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 la performance d'un index ou pour un tri applicatif sans colonne created_at dédiée. Nanoid vise la chaîne la plus courte possible à budget d'entropie donné, en particulier dans une URL. Aucun des trois ne remplace un contrôle d'autorisation côté serveur, et aucun n'est fait pour une génération à fort débit dans le navigateur — c'est le rôle des bibliothèques uuid, ulid et nanoid côté serveur. Si ces identifiants transitent dans une charge JSON d'API, le guide sur l'optimisation d'une API REST JSON complète cette lecture, tout comme le validateur de schéma JSON pour vérifier le format attendu d'un champ id.

Générer un identifiant dans le navigateur

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 : bibliothèque serveur (uuid, ulid, nanoid), pas le générateur navigateur

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

Un identifiant aléatoire, triable ou compact : trois besoins différents

Choisir le bon outil selon le contexte

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

Format, taille, tri : ce qui distingue vraiment les quatre variantes

Générer, ajuster, copier

Étape 1 — Choisir la version ou l'option de tri

Étape 2 — Ajuster tirets, casse et format

Étape 3 — Régler le nombre d'ID (1 à 50) puis copier

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

Exemple de base

Exemple de base

Exemple de base

Conclusion

Articles connexes