Generador de UUID — v4, v7 y nil

Genera UUIDs frescos (v4 o v7) en tu navegador usando la API Web Crypto. Elige la cantidad, copia un solo valor o todos a la vez. Nada se envía a un servidor.

¿Qué es un UUID?

Un UUID (identificador único universal) es un valor de 128 bits formateado como 32 caracteres hexadecimales en cinco grupos separados por guiones (8-4-4-4-12). Dos UUIDs bien elegidos tienen una probabilidad ínfima de colisión, incluso generados en máquinas separadas sin coordinación — propiedad ideal para claves primarias, IDs de petición, nombres de archivo y tokens de idempotencia.

El UUID v4 es totalmente aleatorio y ha sido el predeterminado durante años. El UUID v7 (RFC 9562, 2024) integra una marca de tiempo Unix en milisegundos en los primeros 48 bits, lo que hace los IDs ordenables por fecha de creación y mucho más amigables con los índices de bases de datos. El UUID nil es un placeholder de todos ceros usado para indicar 'sin valor' en campos que requieren un UUID.

Cómo usar esta herramienta

Elige una versión de UUID: v4 para aleatoriedad pura, v7 para IDs ordenables por tiempo, nil para el centinela todo-cero.
Elige cuántos generar de una vez (1 a 100). La lista se regenera al instante cada vez que cambias un parámetro.
Haz clic en Copiar junto a una fila para tomar un solo valor, o Copiar todos para poner toda la lista (un UUID por línea) en tu portapapeles.

Preguntas frecuentes

¿Estos UUIDs son criptográficamente seguros?

Sí. Usamos crypto.randomUUID() (o crypto.getRandomValues() como respaldo) del navegador, ambos exponen el CSPRNG de la plataforma. Los bits aleatorios sirven para identificadores de sesión no adivinables y tokens secretos.

¿Debo usar v4 o v7 en mi base de datos?

v7 suele ser el mejor predeterminado. Como los IDs v7 ordenan por fecha de creación, los índices B-tree (predeterminados en PostgreSQL, MySQL, SQL Server) permanecen compactos y las inserciones golpean la página derecha. v4 fragmenta los índices y ralentiza inserciones en tablas grandes.

¿Pueden colisionar dos UUIDs generados?

En teoría sí; en la práctica no. v4 tiene 122 bits aleatorios — generar mil millones de v4 por segundo durante cien años aún da una probabilidad de colisión inferior a 1 entre mil millones. v7 mezcla 74 bits aleatorios con una marca de tiempo, así que dos colisiones requerirían el mismo milisegundo y sufijo aleatorio idéntico.

¿Qué significa 'ordenable' para v7?

Ordena los IDs lexicográficamente (orden de string) y los obtienes por fecha de creación. Esa propiedad elimina la necesidad de una columna created_at separada cuando solo necesitas un orden grosero, y hace eficientes las consultas por bucket de tiempo incluso sin un índice en una columna timestamp.

¿Es seguro usar el UUID nil?

Es un UUID válido y útil como placeholder, pero nunca lo uses para una entidad real — muchos ORMs y frameworks lo tratan como 'ausente'. Si tu base tiene una columna UUID NOT NULL con valor por defecto, prefiere DEFAULT gen_random_uuid() (Postgres) o un v7 generado en lugar del valor nil.

Casos de uso comunes

Donde echar mano de un UUID es la decisión correcta.

Claves primarias de base de datos

Evita IDs enteros secuenciales que filtran volumen de negocio en URLs y permiten a atacantes iterar. Los UUIDs son no adivinables, pueden generarse del lado cliente sin ida y vuelta a la base, y se fusionan limpiamente entre sistemas distribuidos.

Claves de idempotencia para peticiones API

Genera un UUID por acción lógica de usuario y pásalo como header Idempotency-Key. El servidor puede entonces deduplicar reintentos de forma segura — exactamente el patrón que usan Stripe y otras APIs de pago.

IDs de correlación en logs distribuidos

Adjunta el mismo UUID a cada línea de log, span y petición downstream que produce una sola acción de usuario. Buscar ese ID en tu agregador trae todo el rastro entre servicios.

Nombres de archivo únicos

Nombrar archivos subidos como <uuid>.<ext> evita colisiones de nombres, elimina la necesidad de sanitizar entrada del usuario y previene ataques de path-traversal vía nombres de archivo manipulados.

Consejos y atajos

Hábitos que hacen los UUIDs más fáciles de convivir.

Prefiere v7 para esquemas nuevos

A menos que tengas una razón específica para querer IDs totalmente desordenados (seguridad por oscuridad en URLs, por ejemplo), v7 es más rápido en disco, más fácil de depurar — puedes leer la marca de tiempo — y tan resistente a colisiones como v4.

Almacena como UUID nativo, no como string

PostgreSQL, MySQL 8 y SQL Server tienen tipos UUID/UNIQUEIDENTIFIER nativos que almacenan 16 bytes en lugar de 36. El ahorro de espacio importa a escala y la comparación es más rápida.

No expongas v1 o v2 públicamente

v1 filtra la dirección MAC de la máquina generadora. v2 (DCE Security) filtra el UID POSIX. Ambos son obsoletos; usa v4 o v7 en su lugar.

Recorta los guiones si debes acortar

Eliminar los cuatro guiones reduce la string de 36 a 32 caracteres y es reversible. Evita codificar los bytes en Base64 — el resultado es más corto (22 caracteres) pero ya no se reconoce como UUID y rompe herramientas que esperan el formato canónico.