Generador de UUID online

Qué hay dentro de un UUID

Un UUID son 128 bits que se escriben como 32 dígitos hexadecimales agrupados 8-4-4-4-12. Dos de esos dígitos no son datos: son metadatos que dicen cómo se generó el identificador.

  f47ac10b-58cc-4372-a567-0e02b2c3d479
                     ↑    ↑
                     │    └── variante: 8, 9, a o b (RFC 4122)
                     └─────── versión: 1, 3, 4, 5, 7…

El primer dígito del tercer grupo es la versión, y el primero del cuarto es la variante. Por eso un UUID v4 legítimo siempre tiene un 4 en la posición 15 y un 8, 9, a o b en la 20. Hay validadores que lo comprueban, y una cadena hexadecimal aleatoria de 32 caracteres no es un UUID válido aunque lo parezca: casi seguro fallará esas dos posiciones.

v4 y v1: la diferencia importa más de lo que parece

El punto de seguridad es concreto: un UUID v1 en una URL pública revela cuándo se creó el registro, y con eso se puede inferir el volumen de tu sistema —generas dos registros con un minuto de diferencia y comparas los identificadores—. Para cualquier cosa que el usuario pueda ver, usa v4.

Por qué Math.random no vale

Esta herramienta usa crypto.getRandomValues, la fuente de aleatoriedad criptográfica del navegador. La diferencia con Math.random() no es teórica:

// MAL: Math.random no es criptográficamente seguro y su estado
// interno es predecible a partir de suficientes salidas.
const malo = 'xxxxxxxx-xxxx-4xxx'.replace(/x/g, () =>
  Math.floor(Math.random() * 16).toString(16));

// BIEN: la API del navegador, y desde 2021 hay una función dedicada
crypto.randomUUID();                     // v4 en una línea

// O a mano, si necesitas controlar el formato:
const b = crypto.getRandomValues(new Uint8Array(16));
b[6] = (b[6] & 0x0f) | 0x40;             // versión 4
b[8] = (b[8] & 0x3f) | 0x80;             // variante RFC 4122

Fíjate en las dos últimas líneas: hay que forzar los bits de versión y variante a mano. Es el paso que se olvida en las implementaciones caseras, y produce identificadores que un validador estricto rechaza.

¿Puede repetirse un UUID?

En la práctica, no. Un v4 tiene 122 bits aleatorios, lo que da unos 5 × 10³⁶ valores posibles. Para tener una probabilidad del 50 % de una sola colisión habría que generar del orden de 2,7 × 10¹⁸ identificadores: si generaras mil millones por segundo, tardarías unos ochenta y cinco años.

La advertencia real no es la colisión matemática, es la mala fuente de aleatoriedad. Un generador que use Math.random mal sembrado, o que reinicie su estado en cada arranque, sí puede repetir valores. Ahí es donde ocurren las colisiones de verdad.

Qué probar con UUID sintéticos

• La longitud del campo. Con guiones son 36 caracteres; sin ellos, 32. Un VARCHAR(32) corta el UUID con guiones y lo corrompe en silencio.
• Mayúsculas y minúsculas. El estándar los escribe en minúsculas, pero Microsoft y algunas bases de datos los devuelven en mayúsculas. Son el mismo UUID: si comparas cadenas sin normalizar, no lo verás.
• Con y sin guiones. Igual: el mismo identificador con dos representaciones. Normaliza antes de guardar y antes de comparar.
• Entre llaves. {f47ac10b-…} es lo que devuelven algunas API de Windows. Si tu validación no las quita, falla.
• La versión. Genera de las dos versiones si tu sistema las distingue, y comprueba que el validador acepta ambas.
• Como clave primaria. Un lote de 100 sirve para medir qué pasa con los índices: un UUID v4 como clave agrupada fragmenta el índice porque llega desordenado, y ahí es donde la v1 —o la v7— tienen ventaja.

Sobre la versión 7

Existe una versión 7, más reciente, que combina lo mejor de las dos: es ordenable por tiempo pero sin revelar la dirección MAC, y es hoy la recomendación para claves de base de datos nuevas. Esta herramienta genera v1 y v4, no v7. Lo decimos para que no la busques aquí: si tu proyecto la necesita, tendrás que generarla con la biblioteca de tu lenguaje.