Un UUID son 128 bits escritos como 32 dígitos hexadecimales con la familiar forma 8-4-4-4-12. La promesa es que puedes acuñar uno en cualquier máquina, en cualquier momento, sin pedir permiso a nadie, y aun así no colisionar nunca con un UUID acuñado en otra parte. Esta herramienta genera la versión 4: la aleatoria.
La versión 4 son 122 bits aleatorios, no 128
Seis de los 128 bits ya están comprometidos. Cuatro codifican la versión, y por eso todo UUID v4 lleva un "4" literal al principio del tercer grupo. Otros dos codifican la variante, y por eso el cuarto grupo siempre empieza por 8, 9, a o b. Todo lo demás —122 bits— es aleatorio.
Eso deja sitio para unos 5,3 × 10³⁶ valores. El número que de verdad importa es la probabilidad de colisión, y la cota del cumpleaños sitúa un 50% de posibilidades de que haya algún duplicado en torno a 2,7 × 10¹⁸ UUID. Para llegar ahí tendrías que generar mil millones por segundo durante unos ochenta y cinco años. En la práctica, si estás colisionando, lo que está roto es tu fuente aleatoria, no tus probabilidades.
De dónde viene la aleatoriedad importa más que la versión
Este generador usa crypto.getRandomValues(), la fuente aleatoria criptográficamente segura del navegador. No es una elección cosmética. La alternativa obvia, Math.random(), no es un CSPRNG: V8 la implementa con xorshift128+, un algoritmo pensado para velocidad y calidad estadística, no para imprevisibilidad. Observa suficientes de sus salidas y podrás reconstruir su estado interno y predecir todos los valores que producirá.
Para un UUID que solo debe ser único, esa diferencia no importa. Importa enormemente en cuanto se espera que un UUID sea además inadivinable: un enlace de restablecimiento de contraseña, una URL de invitación, la compartición "secreta" de un documento. Son justo los sitios donde los UUID v4 se usan como tokens, y un generador basado en Math.random los convierte en una vulnerabilidad que ninguna prueba detectará jamás. Si te llevas una sola cosa de esta página: comprueba qué usa tu biblioteca de UUID antes de tratar su salida como un secreto.
La cuestión de la clave primaria
Los UUID aleatorios son excelentes identificadores y claves primarias agrupadas mediocres, y conviene saber por qué antes de fijar un esquema. Las bases de datos mantienen los índices B-tree ordenados. Los enteros autoincrementales siempre se añaden a la página más a la derecha, lo cual es barato. Los UUID v4 aleatorios caen en cualquier sitio, así que las inserciones se dispersan por todo el índice, forzando divisiones de página y ensuciando páginas por todo el buffer pool.
Muerde más fuerte en MySQL con InnoDB, donde la clave primaria es el índice agrupado: la propia tabla está ordenada físicamente por ella, y cada índice secundario lleva una copia de la clave primaria. Ahí una clave aleatoria de 16 bytes cuesta el doble. Es exactamente el problema que la versión 7 de UUID se estandarizó para resolver: coloca una marca de tiempo en milisegundos en los bits altos, así los valores se ordenan aproximadamente por fecha de creación y las inserciones se quedan cerca del borde derecho, conservando aleatoriedad suficiente para seguir siendo inadivinables. Si quieres UUID como claves primarias a volumen, v7 o ULID es la respuesta moderna. Esta herramienta genera v4, que es la elección correcta para identificadores que no son además el orden físico de tu tabla.
Los formatos son cosméticos, casi siempre
Con guiones, sin ellos, en mayúsculas, con llaves: los cuatro representan los mismos 128 bits y cualquier analizador sensato los acepta todos. El estilo con llaves viene de las convenciones GUID de Microsoft y es lo que verás en el registro de Windows y en las interfaces COM. La forma compacta de 32 caracteres es cómoda donde la longitud pesa, como un segmento de URL.
Una advertencia: el RFC 9562 especifica minúsculas para la salida, mientras que los analizadores deben aceptar ambas cajas en la entrada. Si guardas los UUID como cadenas en vez de como tipo nativo de 16 bytes, una caja inconsistente puede producir dos filas que son el mismo UUID y no se comparan como iguales. Es un error autoinfligido, y normalizar a minúsculas a la entrada lo evita.
Preguntas frecuentes
¿Se generan los UUID en un servidor?
No. Esta herramienta está marcada como "client": cada valor lo produce la pestaña de tu navegador con su propia fuente aleatoria, y no se transmite nada. Esa es también la respuesta honesta a si son solo tuyos: aquí nadie tiene registro de ellos, nosotros incluidos.
¿Pueden dos UUID v4 ser iguales alguna vez?
Matemáticamente sí, en la práctica no, con un gran asterisco. Las probabilidades son despreciables solo si la aleatoriedad subyacente es sólida. Los incidentes reales de UUID duplicados casi siempre se remontan a una fuente rota: un PRNG con semilla fija, una máquina virtual clonada junto con su reserva de entropía, o un dispositivo embebido que genera claves antes de haber reunido entropía. El riesgo no son las matemáticas; es la fuente aleatoria.
¿Es seguro usar un UUID v4 como token secreto?
Si viene de una fuente criptográficamente segura, 122 bits aleatorios sobran: cómodamente más que un token de sesión típico de 128 bits. Pero la condición es toda la respuesta. Verifica que tu generador use crypto.getRandomValues o el equivalente de la plataforma en lugar de Math.random, y nunca des por hecho que una biblioteca lo hizo bien solo porque su salida parece aleatoria.
¿Debo usar un UUID o un entero autoincremental?
Los enteros son más pequeños, más rápidos de indexar y se ordenan de forma natural. Los UUID te permiten generar identificadores sin ir y volver de la base de datos, fusionar conjuntos de datos de sistemas distintos sin renumerar y no revelar cuántos registros tienes: un ID secuencial en una URL le cuenta a todo el mundo tu número de pedidos. Muchos esquemas acaban con ambos: una clave entera interna para la base de datos y un UUID para el mundo exterior.
¿Por qué el tercer grupo siempre empieza por 4?
Ese nibble es el campo de versión, y 4 significa "generado a partir de números aleatorios". No es aleatorio él mismo: es una etiqueta. Verlo es cómo un analizador sabe que debe interpretar el resto como v4 y no como una marca de tiempo v1 o un hash v5. Si generas 2000 aquí, los 2000 lo tendrán.