Génération d'UUID en ligne, gratuite

Générez instantanément des valeurs UUID v4 aléatoires.

Aucune donnée ne quitte votre appareil

Génération rapide

Génération en masse

Nombre :

MAJUSCULES {accolades} Sans tirets

À propos des UUID

Un UUID (Universally Unique Identifier, ou identifiant unique universel) est un identifiant de 128 bits conçu pour être unique dans l'espace et dans le temps. La version la plus répandue, UUID v4, est générée à partir de nombres aléatoires ou pseudo-aléatoires. Le format se compose de 8-4-4-4-12 caractères hexadécimaux, par exemple 550e8400-e29b-41d4-a716-446655440000.

Une histoire de quatre décennies, d’Apollo à RFC 9562

Le concept d’UUID est né dans le Apollo Network Computing System (NCS) au milieu des années 1980, conçu chez Apollo Computer par Paul Leach et Rich Salz pour soutenir l’informatique distribuée sans enregistrement central. Le format a été adopté par l’Open Software Foundation Distributed Computing Environment (OSF DCE) en 1989 et standardisé internationalement en 1995 sous ITU-T X.667 / ISO/IEC 9834-8. L’IETF a intégré la spec dans RFC 4122 (Leach, Mealling, Salz) en juillet 2005, qui est devenu la référence canonique pendant deux décennies. RFC 4122 a été mis à jour par RFC 9562 en mai 2024, qui a conservé toutes les versions originales (v1 à v5), ajouté trois nouvelles versions (v6, v7, v8), et formellement défini les constantes spéciales « Nil UUID » (tous zéros) et « Max UUID » (tous uns). Le lignage de versions importe parce que chaque version échange différentes propriétés : basée sur le temps (triable, fuyante) ; basée sur le nom (déterministe à partir des entrées) ; aléatoire (universelle, opaque) ; personnalisée (ce dont vous avez besoin). La meilleure pratique moderne pour les nouvelles applications est passée de v4 (aléatoire) à v7 (timestamp + aléatoire) pour les clés primaires, tandis que v4 reste la bonne réponse pour les identifiants opaques où la triabilité est indésirable.

Les huit versions, en français clair

v1 (timestamp + adresse MAC). 60 bits de timestamp (intervalles de 100 nanosecondes depuis l’époque grégorienne 1582) plus l’adresse MAC de la machine d’origine. L’inconvénient majeur : elle fuite l’adresse MAC de la machine génératrice, ce qui est une préoccupation de confidentialité. L’auteur du virus Melissa a été fameusement identifié en 1999 en partie en traçant des UUID v1 dans des documents Word jusqu’à une machine spécifique.
v2 (DCE security). Variante de v1 qui inclut un POSIX UID/GID. Presque jamais utilisée en pratique ; documentée pour exhaustivité.
v3 (basé sur le nom, MD5). UUID déterministe dérivé du hash MD5 de (UUID de namespace + chaîne de nom). Les mêmes entrées produisent toujours le même UUID, utile pour traduire des clés naturelles (URL, noms de domaine, distinguished names) en forme UUID.
v4 (aléatoire). 122 bits d’aléa (les 6 bits restants sont les tags de version + variant). La version la plus largement utilisée, la défaut que presque toute bibliothèque « donne-moi un UUID » retourne.
v5 (basé sur le nom, SHA-1). Identique à v3 mais utilisant SHA-1 au lieu de MD5. Préférée à v3 pour les nouvelles applications parce que SHA-1 est moins cassé que MD5, même si les deux ont des attaques de collision connues.
v6 (RFC 9562, mai 2024, ordonnée par le temps). Réordonne les bits de timestamp v1 pour que le tri lexicographique corresponde au tri chronologique. Résout la plainte « v1 ne se trie pas par temps » ; fuite encore l’adresse MAC par défaut.
v7 (RFC 9562, mai 2024, timestamp Unix + aléa). Les 48 premiers bits sont le timestamp Unix en millisecondes ; les 74 bits restants sont aléatoires. Se trie naturellement par temps de création, inclut des données de timestamp sans fuiter l’identité de la machine, et est la recommandation moderne pour les clés primaires de base de données. Postgres 18+ a uuidv7() intégré ; SQL Server a NEWSEQUENTIALID() avec des propriétés similaires.
v8 (personnalisé). Réservé pour des layouts spécifiques à l’application. Le champ version le marque comme v8 et les bits de variant sont définis correctement ; tout le reste dépend de l’application. Utiliser quand vous devez incorporer vos propres données structurées dans l’enveloppe en forme d’UUID.

Pourquoi v7 est de plus en plus préférée à v4 pour les clés de base de données

Les clés primaires aléatoires (UUID v4) ont un coût de performance bien documenté dans les bases de données qui organisent les lignes par clé primaire dans un B-tree ou un index similaire. Chaque nouvelle insertion atterrit à une position aléatoire dans l’index, ce qui fragmente les pages d’index, augmente l’amplification d’écriture sur disque, et fracasse le cache de pages parce que les lignes récemment insérées sont éparpillées sur beaucoup de pages au lieu d’être groupées. Les clés séquentielles (entiers auto-incrémentés, ULID, UUID v7) s’insèrent toutes au bord droit de l’index, ce qui garde le working set petit et l’amplification d’écriture minimale. La critique de l’« anti-pattern de clé aléatoire » remonte à la documentation SQL Server des débuts autour de NEWID versus NEWSEQUENTIALID, et a été ré-articulée par la communauté Postgres pour v4 vs v7. Le compromis : v7 fuite le temps de création de chaque ligne, ce qui peut être une préoccupation de confidentialité ou de fuite d’information dans certaines applications (par exemple vous pouvez dire quand un compte a été créé en lisant son UUID). Pour la plupart des applications, le gain de performance l’emporte sur la fuite de timestamp ; pour les applications à haute confidentialité, v4 reste la bonne réponse.

Probabilité de collision, les maths du paradoxe des anniversaires

UUID v4 a 122 bits d’aléa, ce qui donne approximativement 5,3 × 10³⁶ valeurs possibles. Le paradoxe des anniversaires dit que vous avez besoin approximativement de la racine carrée de la taille du namespace pour avoir 50 % de chance de toute collision, environ 2,3 × 10¹⁸ UUID. Pour mettre cela en termes humains : si vous générez 1 milliard d’UUID par seconde en continu, il vous faudrait environ 86 ans pour avoir 50 % de chance d’une seule collision. Pour les taux de génération à l’échelle applicative ordinaire (milliers ou millions par jour), le risque pratique de collision est zéro. La cause la plus probable d’« UUID dupliqués » dans les vrais systèmes est un générateur buggé utilisant Math.random() au lieu d’un CSPRNG, ou un générateur avec une entropie insuffisante au démarrage, ou un processus qui amorce accidentellement deux générateurs à l’identique, pas les mathématiques sous-jacentes. Ce générateur utilise crypto.randomUUID() du navigateur (où disponible) ou crypto.getRandomValues(), tous deux puisant dans le CSPRNG du système d’exploitation (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes), la même source d’entropie utilisée pour les clés de session TLS.

Implémentation navigateur : crypto.randomUUID()

L’API Web Crypto expose crypto.randomUUID() comme un générateur en un appel qui retourne une chaîne UUID v4 conforme à RFC 4122. Il a été livré dans Chrome 92 (juillet 2021), Firefox 95 (décembre 2021) et Safari 15.4 (mars 2022), et est baseline-disponible dans tous les navigateurs modernes depuis approximativement 2022. Pour les navigateurs plus anciens, le fallback standard est d’allouer un Uint8Array de 16 octets, le remplir avec crypto.getRandomValues(), définir le nibble de version à 4 (le nibble haut du 7e octet = 0x40), définir les bits de variant à 10xxxxxx (les deux bits hauts du 9e octet = 0x80), et formater les octets en chaîne hex 8-4-4-4-12. Ce générateur utilise crypto.randomUUID() quand présent et le fallback manuel sinon, la sortie est identique dans les deux cas, juste légèrement plus lente sur le chemin fallback. Les deux chemins tournent entièrement dans votre navigateur ; rien ne traverse le réseau.

Cas d’usage, et ce dont chacun a réellement besoin

Clés primaires de base de données: spécialement les systèmes distribués ou shardés où coordonner un compteur entier est impraticable. v7 est la recommandation moderne ; v4 si vous avez besoin d’opacité de timestamp.
IDs de corrélation de requêtes API. Chaque requête entrante reçoit un UUID qui voyage à travers tout service en aval dans la chaîne d’appel ; les logs de tout service peuvent être rattachés à la requête d’origine via l’ID. Stripe, Twilio et AWS X-Ray font tous cela.
Clés d’idempotence pour requêtes HTTP. L’en-tête Idempotency-Key de Stripe prend un UUID ; si le client réessaie la même requête avec la même clé, Stripe retourne la réponse en cache au lieu de débiter la carte deux fois. Ce pattern est désormais standard parmi les API de paiement.
Tokens de session, avec mises en garde. Un UUID v4 est cryptographiquement aléatoire et a 122 bits d’entropie, ce qui est plus que suffisant pour un ID de session. Mais les tokens de session qui sont uniquement un UUID sont vulnérables aux attaques d’énumération si tout endpoint lié les fuite ; la meilleure pratique moderne est d’utiliser des tokens plus longs et signés (JWT, Paseto) pour l’état de session.
Noms de fichiers pour la déduplication d’upload. Générez un UUID pour chaque upload, stockez le fichier à /uploads/{uuid}.ext: vous n’aurez jamais de collision de nom indépendamment du nom de fichier original, et vous ne pouvez pas accidentellement servir le fichier d’un autre utilisateur en devinant l’URL.
IDs de message dans les systèmes événementiels. Kafka, RabbitMQ, AWS SQS et la plupart des plateformes pub/sub recommandent un UUID par message pour le tracing et la déduplication ; v7 est de plus en plus le défaut pour la propriété triable par timestamp.
Génération de données de test. Les bibliothèques Faker dans toutes les langues utilisent des UUID comme IDs par défaut pour les lignes de test générées.
Identifiants de nœuds de système distribué. Un nouveau nœud qui démarre dans un cluster génère un UUID pour lui-même ; le coordinateur du cluster utilise cet ID pour router le trafic et identifier le nœud dans les logs.

Alternatives qui valent la peine d’être connues

UUID est le défaut universel mais pas la seule option, et plusieurs alternatives valent la peine d’être connues pour des cas d’usage spécifiques. ULID (Universally Unique Lexicographically Sortable Identifier, Alex Knol, ~2016) : 128 bits comme UUID, mais encodé en 26 caractères Crockford-Base32 au lieu de 32 chiffres hex, plus compact et URL-safe insensible à la casse. Les 48 premiers bits sont un timestamp Unix en millisecondes, donc les ULID se trient lexicographiquement par temps de création. Conceptuellement très proche d’UUID v7, le précédant de plusieurs années. Snowflake (Twitter, 2010) : 64 bits, beaucoup plus petit qu’UUID, tient dans un BIGINT SQL. 41 bits de timestamp + 10 bits d’ID machine + 12 bits de séquence par milliseconde. Utilisé par Twitter/X, Discord, Instagram, et beaucoup de systèmes à grande échelle où les clés primaires 64 bits sont une contrainte dure. KSUID (Segment, 2017) : 27 caractères, timestamp à précision seconde + 128 bits d’aléa. Échange la précision milliseconde pour une représentation chaîne plus petite qu’UUID. nanoid (Andrey Sitnik, 2017) : une bibliothèque minuscule qui produit des identifiants aléatoires URL-safe de longueur configurable. Le défaut de 21 caractères fournit une résistance aux collisions similaire à UUID v4 en beaucoup moins d’octets. Pour une URL publique où vous incorporeriez sinon un UUID, nanoid est plus court et plus convivial. Le compromis : les identifiants nanoid n’ont pas les bits de marqueur version + variant qui les distinguent comme UUID, donc ils ne s’insèrent pas dans des systèmes qui attendent des valeurs en forme d’UUID.

Sécurité d’URL et variations de format

Les UUID dans leur forme canonique avec tirets (550e8400-e29b-41d4-a716-446655440000) sont URL-safe, chaque caractère (lettres minuscules, chiffres, tirets) est dans le jeu non réservé défini par RFC 3986. Cela signifie que vous pouvez déposer un UUID directement dans un path d’URL ou une query string sans percent-encoding. Certains systèmes retirent les tirets pour la compacité, produisant une chaîne hex de 32 caractères (550e8400e29b41d4a716446655440000) qui est toujours URL-safe ; la conversion est réversible parce que la structure UUID est fixe. Quelques systèmes enveloppent les UUID dans des accolades ({550e8400-e29b-41d4-a716-446655440000}), la convention GUID de Microsoft ; les accolades sont décoratives et ne voyagent jamais dans les URL. Certains systèmes mettent les caractères hex en majuscules ; les UUID sont insensibles à la casse selon la spec, mais la cohérence dans un système compte. Ce générateur offre les trois options (majuscules, accolades, sans tirets) pour compatibilité avec n’importe quel pipeline auquel vous nourrissez les UUID.

UUID vs GUID, la même chose, un nom différent

UUID est le terme standard utilisé par l’IETF, l’ISO et la plupart des projets open-source. GUID (Globally Unique Identifier) est le terme Microsoft utilisé dans Windows, .NET, COM/OLE, SQL Server, Active Directory et le Registre Windows. Tous deux se réfèrent à l’identifiant 128 bits identique dans le même format hex 8-4-4-4-12. Fonctionnellement interchangeables, un GUID généré par Windows peut être utilisé partout où un UUID est attendu, et vice versa. La seule différence à connaître : la génération de GUID de Microsoft a historiquement utilisé UUID v4 dans beaucoup d’API mais UUID v1 (avec adresse MAC) dans certains contextes COM/OLE plus anciens ; c’est documenté dans la spécification COM de Microsoft. Si vous recevez un GUID d’un système d’origine Microsoft et voulez savoir quelle version c’est, vérifiez le nibble de version (le 13e caractère hex, '1' pour v1, '4' pour v4, etc.).

Confidentialité : pourquoi le tout-navigateur compte même ici

Un UUID n’a aucune signification intrinsèque, alors pourquoi cela importe-t-il que le générateur tourne localement ? Deux raisons. Premièrement, quand un UUID est utilisé comme token de session, clé d’idempotence ou tout autre identifiant ressemblant à un secret, le générer sur un serveur tiers signifie que ce serveur a vu la valeur avant que vous ne l’utilisiez, une exposition petite mais réelle. Deuxièmement, les générateurs côté serveur qui promettent un « aléa cryptographique » ne peuvent pas être vérifiés par l’utilisateur ; un serveur buggé ou malveillant pourrait retourner des valeurs non-aléatoires qui ont l’air aléatoires, et vous n’auriez aucun moyen de détecter le biais. Un générateur tout-navigateur exécute le même appel crypto.randomUUID() que votre application exécuterait côté serveur ; l’entropie vient de la même source de système d’exploitation (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes) ; aucune tierce partie ne voit la sortie. Vous pouvez le vérifier en ouvrant l’onglet Réseau des DevTools pendant que vous cliquez sur Générer, il n’y a pas de requêtes sortantes. Mettez la page hors ligne (mode avion) après son chargement et le générateur fonctionne toujours.

Questions fréquentes

Quelle est la différence entre UUID et GUID ?

Ce sont essentiellement la même chose. UUID est le terme standard (RFC 4122), tandis que GUID (Globally Unique Identifier, ou identifiant unique global) est la terminologie Microsoft. Les deux désignent un identifiant de 128 bits au même format hexadécimal 8-4-4-4-12.

Deux UUID peuvent-ils être identiques ?

En théorie, oui, mais la probabilité est astronomiquement faible. UUID v4 dispose de 122 bits aléatoires, soit environ 5,3 × 10³⁶ valeurs possibles. Il faudrait générer des milliards d'UUID par seconde pendant des décennies pour avoir 50 % de chances d'obtenir une seule collision.

Ces UUID sont-ils cryptographiquement sûrs ?

Oui. Ce générateur utilise la Web Crypto API (crypto.getRandomValues), qui fournit des valeurs aléatoires cryptographiquement robustes. Le résultat convient aux cas d'usage sensibles à la sécurité, comme les jetons de session.

Devrais-je utiliser UUID v4 ou v7 pour ma clé primaire de base de données ?

v7 est la recommandation moderne si votre base de données la supporte. v4 (aléatoire) s’insère à des positions aléatoires dans les index B-tree, fragmente l’index, et fracasse le cache de pages. v7 (timestamp + aléa, RFC 9562 mai 2024) s’insère au bord droit de l’index parce que les IDs se trient par temps de création, même performance d’écriture que les entiers auto-incrémentés, avec la distribution et l’unicité des UUID. Postgres 18+ a uuidv7() intégré. Le compromis : v7 fuite le temps de création de chaque ligne, ce qui peut être une préoccupation de confidentialité dans certaines applications. Pour la plupart des cas d’usage, le gain de performance l’emporte sur la fuite de timestamp.

Que sont ULID, KSUID et nanoid ?

Des formats d’ID alternatifs. ULID (Alex Knol, ~2016) : 128 bits comme UUID mais encodés en 26 caractères Crockford-Base32 ; se trient lexicographiquement par timestamp. KSUID (Segment, 2017) : 27 caractères, timestamp à précision seconde + 128 bits aléatoires. nanoid (Andrey Sitnik, 2017) : bibliothèque minuscule produisant des IDs URL-safe aléatoires de longueur configurable ; le défaut de 21 caractères donne une résistance aux collisions similaire à UUID v4 en beaucoup moins d’octets. Snowflake (Twitter, 2010) : IDs 64 bits qui tiennent dans un BIGINT SQL, utilisés par Twitter, Discord et Instagram. Utilisez UUID quand le système destinataire attend le format UUID ; utilisez les alternatives quand vous avez des exigences spécifiques de taille, triabilité ou convivialité d’URL.

Les UUID sont-ils envoyés quelque part ?

Non. Chaque UUID est généré localement dans votre navigateur en utilisant l’API Web Crypto. Le générateur ne fait jamais de requête réseau, vérifiez dans l’onglet Réseau des DevTools pendant que vous cliquez sur Générer, ou mettez la page hors ligne après son chargement et confirmez que l’outil fonctionne toujours. Sûr pour générer des tokens de session, des clés d’idempotence ou d’autres identifiants où vous ne voulez pas qu’une tierce partie ait vu la valeur avant que vous ne l’utilisiez.