Encoders & Utilities

Générateur UUID

Génère UUID v1, v4, v7, NIL ou MAX par lot. Toggle pour majuscules, accolades ou format sans tirets.

Version

v4 — random v7 — time-ordered (RFC 9562) v1 — time + node NIL — all zeros MAX — all ones

Quantity Between 1 and 1000.

UPPERCASE Wrap in {braces} No dashes

When to use which version

v1 — time-based + MAC node. Good when ordering matters and you need debuggable insertion order. Leaks MAC/host info if real MAC is used; we generate a random multicast-bit node so no real hardware is exposed.
v4 — random. Default choice. Collision-resistant (2¹²² entropy), good for distributed systems where ordering doesn't matter. Bad for DB primary keys at scale (random order kills B-tree locality).
v7 — time-ordered (RFC 9562, 2024). 48-bit Unix-ms timestamp prefix → lexicographically sortable + index-friendly. Recommended for new DB primary keys. Use this if you can.
NIL — 00000000-0000-0000-0000-000000000000. Sentinel/placeholder value.
MAX — all-ones UUID (RFC 9562). Useful as "infinity" sentinel paired with NIL.

À propos de cet outil

UUID Generator émet des Identifiants Universellement Uniques de 128 bits conformes à la RFC 9562 (la mise à jour 2024 de la RFC 4122 originale). Cinq variantes sont prises en charge : v1 (temps + MAC, prévisible dans le temps), v4 (aléatoire — la plus courante), v7 (aléatoire ordonné dans le temps, le défaut moderne pour les clés de base de données), NIL (espace réservé tout zéro), et MAX (tout-FF — utile comme limite « maximale » dans les requêtes de plage). Générez-en un ou jusqu'à 1000 à la fois.

Toute la randomness vient de crypto.getRandomValues() — le même CSPRNG navigateur utilisé par TLS. Les UUID ne se répètent jamais en pratique : les 122 bits de randomness de v4 donnent une probabilité de collision si faible que générer un milliard par seconde pendant 85 ans a environ 50 % de chances d'une seule collision (la « borne d'anniversaire » pour 122 bits). v7 réduit la randomness à 74 bits en échange de l'ordonnancement temporel, ce qui reste sûr contre les collisions à toute échelle réaliste.

Quand utiliser cet outil

Générer un ID de base de données d'exemple pour les tests. Plus rapide qu'exécuter le générateur de votre ORM.
Choisir la bonne version. v7 trie par temps lorsqu'utilisé comme clé primaire — bien meilleur pour les index B-tree que v4. N'utilisez v4 que quand vous voulez activement cacher l'ordre.
Seeder des fixtures. 100 UUID distincts en un clic pour un jeu de données de test.
Inspecter un format UUID. Validez qu'une chaîne que vous avez reçue est bien un UUID valide et découvrez quelle version.

À propos de v7 vs v4

UUID v7 a été standardisé en 2024 spécifiquement pour corriger la randomness anti-base-de-données-friendly de v4. v7 a le timestamp (48 bits, résolution milliseconde) dans les bits hauts, donc les UUID fraîchement générés se trient lexicalement par temps de création. Cela garde un index B-tree « serré » (les nouvelles insertions se regroupent à une extrémité) au lieu de se disperser à travers les pages. Pour les nouvelles applications, v7 est le nouveau défaut ; v4 ne reste utile que lorsque vous voulez spécifiquement l'imprévisibilité de l'ordre.

Questions fréquentes

Quelle est la différence entre les UUID v4 et v7 ?

v4 est 122 bits de données aléatoires — l'ordre de deux UUID v4 n'a pas de sens. v7 embarque un timestamp Unix milliseconde de 48 bits dans les bits hauts, donc les UUID v7 générés plus tard trient après ceux générés plus tôt. Pour les clés primaires de base de données, v7 est dramatiquement plus convivial pour les index B-tree ; v4 disperse les écritures sur tout l'index et cause plus de divisions de pages.

Les UUID sont-ils vraiment uniques ?

Effectivement oui. Pour v4, avec 122 bits de randomness, il faudrait générer ~2,7 × 10^18 UUID avant d'avoir 50 % de chances d'une collision. Le monde en génère des billions par an et les collisions ne sont pas un vrai problème. v7 avec 74 bits aléatoires est encore sûr à hauteur de ~1,5 × 10^11 par milliseconde. L'UUID NIL (00000000-...) est la seule exception et est réservé.

Pourquoi certains UUID ont-ils des accolades autour ?

Une convention Microsoft — Windows COM et .NET affichent souvent les GUID comme {xxxxxxxx-xxxx-...}. Les accolades ne font pas partie de la valeur, juste décoratives. La plupart des autres écosystèmes (Linux, API JSON, JavaScript) écrivent les UUID sans accolades. Notre bascule vous permet de produire l'un ou l'autre format ; changez selon les besoins lors de l'interopérabilité avec les stacks lourdes en Windows.

Puis-je les utiliser comme clés primaires de base de données ?

Oui — les UUID sont largement utilisés comme PK. Pour les nouvelles tables, préférez v7 (ou ULID, un format apparenté) afin que l'index reste compact. v4 est techniquement bien mais cause plus d'amplification d'écriture sur les index B-tree en raison de la dispersion aléatoire. PostgreSQL, MySQL 8+ et SQLite ont tous un support UUID natif ou quasi-natif ; dans MySQL pré-8, stockez comme BINARY(16) pour la compacité.