Generador de UUID v4

Generación de UUID v4: 122 bits de aleatoriedad real

El generador de UUID v4 produce identificadores únicos universales basados en 122 bits de aleatoriedad pura por cada identificador. Los 6 bits restantes están fijados por la especificación: 4 para indicar la variante (RFC 4122) y 2 para marcar la versión (v4). El resultado es una cadena de 36 caracteres en el formato canónico 8‑4‑4‑4‑12, por ejemplo f47ac10b-58cc-4372-a567-0e02b2c3d479. Si se desactiva la opción “Include hyphens”, la cadena se reduce a 32 caracteres hex, como f47ac10b58cc4372a5670e02b2c3d479.

La aleatoriedad se obtiene directamente del navegador mediante crypto.randomUUID o APIs equivalentes. Todo el proceso ocurre en local: ningún dato sale del dispositivo. Al cambiar cualquier opción (formato, cantidad, mayúsculas, guiones) los identificadores se regeneran al instante. El rango de cantidad permitido es de 1 a 100, ambos incluidos.

Los 122 bits de entropía hacen que estos UUID no tengan ningún orden intrínseco. A diferencia de los identificadores basados en tiempo, como UUID v7 o ULID, los v4 no pueden ordenarse cronológicamente ni ofrecen localidad de referencia. Esta propiedad es fundamental para entender sus ventajas y sus costes, sobre todo en el ámbito de bases de datos.

Formato canónico y opciones de personalización

La representación estándar de un UUID v4 usa letras minúsculas a‑f y guiones en las posiciones fijas: 8‑4‑4‑4‑12. Sin embargo, la herramienta expone dos toggles que solo aparecen en los generadores de UUID (v4 y v7) del sitio, porque otros tipos de ID (ULID, NanoID) usan controles distintos.

• Mayúsculas (Uppercase): si se activa, los caracteres hex a‑f se muestran como A‑F. La cadena completa, incluidos los guiones, se transforma con mayúsculas. Esto no afecta a la semántica del identificador: un UUID es insensible a mayúsculas en la mayoría de los sistemas, pero ciertos entornos (URLs, logs, formatos impresos) pueden requerir un estilo particular.
• Guiones (Include hyphens): al desactivarlo se eliminan los cuatro guiones, dejando una secuencia continua de 32 dígitos hex. Es útil cuando se necesita un identificador más compacto para URLs o nombres de archivo, siempre que el sistema receptor acepte la omisión de guiones. La especificación original permite tanto la forma canónica con guiones como la forma sin ellos (llamada “UUID sin guiones” o “string simple”). Ambos representan el mismo valor de 128 bits.

Cuando se cambia cualquiera de estas opciones, la regeneración es inmediata. El usuario ve la lista actualizada sin pulsar ningún botón adicional.

Probabilidad de colisión: por qué es despreciable

Con 122 bits aleatorios, la probabilidad de que dos UUID v4 generados de forma independiente coincidan es extremadamente baja. Para hacerse una idea numérica: si se generasen 1000 millones de UUID v4 cada segundo durante los próximos 100 años, la probabilidad de una sola colisión seguiría siendo inferior a 1 entre 10^10. En la práctica, los sistemas que usan UUID v4 para identificar objetos, sesiones o eventos pueden considerar las colisiones como imposibles.

Esta propiedad se basa en la matemática del “problema del cumpleaños”: la probabilidad de colisión crece con el cuadrado del número de UUID generados. Incluso tras generar 2^61 UUID (aproximadamente 2.3×10^18), la probabilidad de colisión alcanza el 50%. Ninguna aplicación real necesita una cantidad ni remotamente cercana. La herramienta limita a 100 por lote, pero incluso acumulando lotes a lo largo de años, el riesgo sigue siendo despreciable.

Es importante señalar que la aleatoriedad debe provenir de una fuente criptográficamente segura. El generador usa crypto.getRandomValues o crypto.randomUUID, que cumplen con ese requisito. No se emplean generadores pseudoaleatorios rápidos como Math.random, que tienen menos entropía y patrones predecibles.

Impacto en bases de datos: fragmentación de índices B‑tree

Quienes diseñan bases de datos relacionales o NoSQL suelen enfrentarse a una decisión: ¿usar UUID v4 como clave primaria? La respuesta depende del motor y del patrón de escritura. Los UUID v4 tienen valores completamente aleatorios, por lo que al insertarlos en un índice B‑tree (el más común en sistemas como PostgreSQL, MySQL o SQL Server) se generan escrituras en posiciones arbitrarias de las páginas del índice. Esto provoca:

• Fragmentación del índice: las páginas se dividen con frecuencia, aumentando la sobrecarga de mantenimiento.
• Pérdida de localidad: los registros nuevos no se agrupan con los existentes, lo que ralentiza las lecturas por rango.
• Mayor uso de espacio: los índices B‑tree pierden eficiencia cuando las claves no son secuenciales.

En cambio, identificadores ordenados como UUID v7 (que incorporan una marca de tiempo de milisegundos) o los secuenciales simples (auto‑incrementales) producen inserciones mayoritariamente al final del índice, reduciendo la fragmentación. Por eso algunas guías recomiendan evitar UUID v4 como clave primaria clustering. Sin embargo, la fragmentación es un problema de rendimiento, no de corrección. Si la aplicación necesita claves impredecibles (por ejemplo, para evitar la enumeración de recursos) y el volumen de escrituras es moderado, UUID v4 sigue siendo una opción válida.

La herramienta advierte de este efecto en su sección “What makes this page different”: “UUID v4 values sort arbitrarily – they carry no time or ordering information, so using them as a primary key fragments B‑tree indexes”. El usuario debe conocer esta limitación antes de decidir.

Comparación con identificadores ordenados por tiempo

El generador ofrece también UUID v7 y ULID en el mismo desplegable de formato. Aunque todos producen identificadores de 128 bits, sus propiedades internas difieren sustancialmente:

La principal ventaja de UUID v7 y ULID es que son ordenables: al ordenarlos lexicográficamente se obtiene la secuencia de creación. Esto los hace más adecuados como claves primarias en índices B‑tree, ya que las inserciones se concentran al final. Sin embargo, al incluir una marca de tiempo, revelan el momento de creación, lo cual puede ser indeseable para ciertos casos de seguridad (tokens de API) o para ocultar el volumen de actividad.

UUID v4, al no contener tiempo, no permite correlacionar temporalmente los identificadores. Es la opción preferida cuando se necesita máxima impredecibilidad y se quiere evitar que un atacante pueda deducir la cadencia de generación.

Casos de uso habituales y buenas prácticas

Los UUID v4 son idóneos en escenarios donde la descentralización y la impredecibilidad son críticas:

• Tokens de API y sesiones: al no contener tiempo, un atacante no puede saber cuándo se generó un token. Combinados con una fuente criptográfica segura, son difíciles de adivinar.
• Identificadores en sistemas distribuidos: cada nodo puede generar UUID sin coordinación central, reduciendo la latencia y evitando puntos únicos de fallo.
• IDs de eventos y logs: permiten correlacionar eventos entre servicios sin depender de un secuenciador común.
• Prevención de enumeración de recursos: en URLs como /usuario/1234, si se usa un secuencial, cualquiera puede probar números vecinos. Con un UUID v4, la enumeración es inviable.
• Población de bases de datos de prueba: los testers generan lotes de hasta 100 UUID v4 con un clic para llenar tablas con datos realistas.

Una mala práctica común es usar UUID v4 como clave primaria en tablas con altísimo volumen de escrituras y lecturas por rango. En esos casos, un UUID v7 o un identificador secuencial ofrecen mejor rendimiento de indexación. Otra equivocación frecuente es confundir la ausencia de guiones con un UUID válido de 32 caracteres: muchos sistemas aceptan ambas formas, pero es preciso verificar la documentación del destino.

Preguntas frecuentes (FAQ)

¿Por qué los UUID v4 no se pueden ordenar por fecha de creación?
Porque no contienen información temporal. Los 122 bits aleatorios no codifican ningún instante. Para ordenar cronológicamente, hay que usar UUID v7 o ULID, que incluyen una marca de tiempo.

¿Cuántos bits de aleatoriedad tiene realmente un UUID v4?
122 bits. Los 6 bits restantes son fijos: 4 para la variante (bits 64-65 valor 10xx) y 2 para la versión (bits 12-13 valor 0100). En total 128 bits.

¿Es seguro usar UUID v4 como clave primaria en una base de datos?
Depende del perfil de carga. Si las escrituras son moderadas (cientos por segundo) y no se necesitan lecturas por rango frecuentes, es aceptable. Para altas tasas de inserción, un identificador secuencial o UUID v7 reduce la fragmentación del índice. La elección debe basarse en pruebas de rendimiento.

¿Qué diferencia hay entre UUID v4 y UUID v7 en cuanto a privacidad?
UUID v4 no revela el momento de generación; v7 sí, porque los primeros 48 bits son una marca de tiempo UNIX. Para tokens o IDs que no deben filtrar información temporal, v4 es más adecuado.

¿Puedo quitar los guiones y seguir teniendo un UUID válido?
Sí. La especificación RFC 4122 define la representación canónica con guiones, pero la cadena de 32 caracteres sin guiones se considera el mismo UUID. Muchas librerías aceptan ambas formas. La opción de la herramienta permite generar la versión compacta, útil para URLs o almacenamiento donde se ahorra espacio.

¿El generador envía los datos a un servidor?
No. Toda la generación ocurre en el navegador usando la API crypto.randomUUID o similar. Ningún ID sale del ordenador del usuario. Al copiar un identificador individual o todos a la vez, la interacción es puramente local (clipboard API).