Generador de UUID
Genera uno o cientos de UUIDs aleatorios (v4).
100% en tu navegador — no se sube nadaGenerar UUID v4 aleatorios en línea
Anatomía de un UUID v4
Ejemplo (los dígitos resaltados son fijos):
3f2b9c1e-7a4d-4f8b-9c2a-5e6d7f8a9b0c
Sobre este generador de UUID
Un UUID (identificador único universal) es un valor de 128 bits que se escribe como 32 dígitos hexadecimales en cinco grupos separados por guiones — 8-4-4-4-12, como fb438932-ab5f-4088-88ad-0c037f96ac0e. Se usa como clave de base de datos, ID de petición o de traza, nombre de archivo y clave de idempotencia: donde necesitas un identificador que puedas crear localmente, sin pedirle permiso a ninguna autoridad central, y con la confianza de que nadie más creó el mismo. Los UUID versión 4, que son los que genera esta página, se construyen casi por completo con datos aleatorios.
El generador llama a crypto.randomUUID(), la fuente criptográficamente segura de tu navegador, que los navegadores exponen únicamente en contextos seguros (HTTPS). En navegadores viejos la página cae a crypto.getRandomValues() y coloca a mano los bits de versión y variante, con un resultado idéntico. Genera hasta 1,000 de una vez, en mayúsculas o sin guiones si lo necesitas, y copia la lista completa con un clic. No se le pide nada a ningún servidor: puedes cargar la página, desconectarte de internet y seguir generando.
De los 128 bits, seis no son aleatorios: cuatro guardan la versión y dos la variante. Quedan 122 bits aleatorios en un v4, y los bits fijos se ven a simple vista en la cadena — el dígito hexadecimal número 13 siempre es 4, y el 17 siempre es 8, 9, a o b. Todo lo demás es entropía. El RFC 9562 acepta mayúsculas, minúsculas o mezcla en la forma textual y las trata como el mismo valor, así que el interruptor de mayúsculas de arriba es puramente cosmético: crypto.randomUUID() devuelve minúsculas, que es lo que guarda casi todo el mundo.
Sobre las colisiones, mejor la cuenta que el susto. Para n identificadores tomados de N = 2^122 posibilidades, el número esperado de colisiones ronda n² / (2N). Llegar a una probabilidad de una en mil millones exige del orden de 10^14 UUIDs, o sea cien billones. En la práctica la aritmética nunca es el problema: lo es la fuente de aleatoriedad. Los UUID generados con Math.random(), con una máquina virtual clonada junto a su pool de entropía, o con un dispositivo embebido que arranca antes de haber juntado entropía, sí se repiten. Si la unicidad de verdad importa, deja la restricción UNIQUE puesta en la columna.
La pregunta que más se repite es si conviene un UUID o un entero autoincremental como clave primaria. A favor del UUID: lo generas en el cliente, no revela cuántos registros tienes y no choca al fusionar bases de datos. En contra: el índice. Como los v4 son aleatorios, cada inserción cae en un punto distinto del árbol B, y el RFC 9562 dice sin rodeos que las versiones de UUID que no están ordenadas por tiempo tienen mala localidad de índice y que el efecto sobre las estructuras B-tree puede ser dramático. El UUIDv7 resuelve eso poniendo un timestamp Unix en milisegundos de 48 bits al inicio, para que las filas nuevas queden juntas al final del índice. El costo también es real: un v7 revela públicamente cuándo se creó, y la propia documentación de PostgreSQL recomienda quedarse en v4 cuando ese dato tenga implicaciones de seguridad o de inteligencia de negocio.
Versiones de UUID comparadas (RFC 9562) y la estructura de bits del v4
El RFC 9562, publicado en 2024, reemplazó al RFC 4122 y añadió las versiones 6, 7 y 8 al conjunto original. La versión 2 (DCE Security) se definió en otro documento y queda fuera del alcance. En el trabajo diario solo aparecen tres, pero ver qué guarda cada una deja claro el porqué.
| Versión | Qué contiene | Cuándo usarla |
|---|---|---|
| v1 | Timestamp gregoriano (unidades de 100 ns desde 1582), secuencia de reloj y nodo | Heredada. El RFC 9562 indica que NO debería usarse una dirección MAC como nodo, porque delata la máquina. |
| v3 | MD5 de un UUID de espacio de nombres más un nombre | IDs deterministas a partir de un nombre, solo si te obligan a usar MD5. |
| v4 | 122 bits aleatorios | La opción por defecto. Impredecible, no revela nada y está soportada en todas partes. |
| v5 | SHA-1 de un UUID de espacio de nombres más un nombre | IDs deterministas: el mismo nombre siempre da el mismo UUID. Preferible al v3. |
| v6 | Los campos del v1 reordenados para que el timestamp ordene primero | Solo para mejorar la localidad en un sistema que ya usa v1. |
| v7 | Timestamp Unix en ms de 48 bits y luego 74 bits de aleatoriedad o contador | Claves primarias. Ordena por fecha de creación y da buena localidad de índice. |
| v8 | Formato libre; solo los bits de versión y variante están fijos | Formatos propios o experimentales que controlas de punta a punta. |
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
| |
| variante: siempre 8, 9, a o b
versión: siempre 4
fb438932-ab5f-4088-88ad-0c037f96ac0eLo que trae cada sistema de fábrica cambió hace poco, así que revisa tus versiones antes de instalar una librería:
| Dónde | v4 | v7 |
|---|---|---|
| PostgreSQL | gen_random_uuid(), nativa desde la 13 | uuidv7(), nueva en la 18, junto con uuid_extract_timestamp() |
| MySQL | No es nativa — UUID() devuelve un v1 | No es nativa |
| Python | uuid.uuid4() | uuid.uuid7(), nueva en 3.14 |
| JavaScript | crypto.randomUUID() | No es nativa — necesitas una librería |
Dos advertencias para cerrar, y las dos cuestan dinero en producción. La primera: guardar un UUID como cadena de 36 caracteres ocupa más del doble de los 16 bytes que realmente necesita, y ese costo se repite en cada índice y cada clave foránea que lo referencia — casi todos los motores tienen un tipo uuid nativo o BINARY(16), úsalo en vez de VARCHAR(36). La segunda: el RFC 9562 pide tratar los UUID de la forma más opaca posible. Si tu código despieza uno para leerle el timestamp, te acabas de amarrar a una versión que quizá quieras cambiar después. Si necesitas la fecha de creación, guarda una columna created_at.
Preguntas frecuentes
¿Pueden chocar dos UUIDs?
Con 122 bits aleatorios, la probabilidad es tan pequeña que se ignora en la práctica: tendrías que generar miles de millones por segundo durante siglos para esperar una colisión.
¿Cuál es la diferencia entre v4 y v7?
v4 es totalmente aleatorio. v7 incluye un timestamp para que los IDs se ordenen por fecha de creación, mejor para índices de bases de datos. v4 sigue siendo el más soportado.
¿Estos UUIDs son seguros para producción?
Sí: provienen de la fuente aleatoria criptográfica de tu navegador, de calidad idéntica a la de una librería de backend.