Generador de UUID — Genera UUID v4 y v7 Online

Genera UUIDs criptográficamente aleatorios al instante. Soporta v4 (aleatorio) y v7 (ordenable por tiempo, RFC 9562). Genera uno o hasta 100 en lote. Usa crypto.randomUUID() — tu navegador hace el trabajo, nada toca un servidor.

Generar UUID únicos
Genera identificadores únicos rápidamente

UUID v4 (Random)

Generated using random numbers. No structure, completely random. Suitable for most use cases.

UUID v7 (Time-based)

Generated using a timestamp and random numbers. Sortable by time, improving database performance.

UUIDs (Universally Unique Identifiers) are 128-bit numbers used to identify information in computer systems. The probability of generating two identical UUIDs is virtually zero.

Explicación de las Versiones UUID

Un UUID es un identificador de 128 bits formateado como 32 dígitos hexadecimales en 5 grupos: 550e8400-e29b-41d4-a716-446655440000. El número de versión se sitúa en el decimotercer carácter (el "4" del ejemplo significa v4).

UUID v4 es pura aleatoriedad — 122 bits aleatorios con 6 bits reservados para los marcadores de versión y variante. La probabilidad de colisión es astronómicamente baja: habría que generar 2,71 × 10^18 UUIDs para tener un 50% de posibilidades de un duplicado. En la práctica, eso es "nunca".

UUID v7 (definido en RFC 9562, publicado en 2024) es el chico nuevo. Pone una marca de tiempo Unix en los primeros 48 bits, seguidos de bits aleatorios. Esto significa que los UUIDs v7 se ordenan cronológicamente — una gran ventaja para los índices de bases de datos. PostgreSQL y MySQL sufren con UUIDs v4 aleatorios como claves primarias porque los índices B-tree se fragmentan mal cuando las inserciones son aleatorias. v7 soluciona esto haciendo que las inserciones siempre vayan al final del índice.

Cuándo usar cuál: v4 para cualquier cosa donde el orden no importe (tokens de sesión, IDs de correlación, claves de idempotencia). v7 para claves primarias de bases de datos, IDs de eventos, o cualquier cosa que vayas a ordenar por tiempo de creación. Si estás comenzando un nuevo proyecto en 2024+, usa v7 por defecto.

Cómo Usar

  1. Selecciona la versión UUID: v4 (aleatorio) o v7 (ordenable por tiempo).
  2. Establece la cantidad — 1 para obtener rápido, hasta 100 para necesidades en lote.
  3. Haz clic en Generar. Los resultados aparecen al instante.
  4. Copia UUIDs individuales o todos a la vez. Minúsculas con guiones, listos para pegar.

Cuándo Lo Utilizarás

Claves primarias de bases de datos en sistemas distribuidos

Los IDs autoincrementados se rompen cuando hay varios nodos de escritura. Los UUIDs permiten que cada nodo genere IDs independientemente con cero coordinación. Usa v7 si necesitas orden cronológico (la mayoría de los casos), v4 si explícitamente no quieres que los IDs revelen el orden de creación.

Claves de idempotencia API

Stripe, AWS y la mayoría de las APIs de pago requieren una clave de idempotencia para evitar cargos duplicados. Genera un UUID v4 por solicitud — si la solicitud falla y reintenta con la misma clave, el servidor sabe que es un reintento, no un nuevo cargo.

Nomenclatura de archivos y objetos en almacenamiento cloud

¿Subir archivos de usuario a S3? Usa un UUID como clave del objeto. Sin colisiones, sin necesidad de sanitizar nombres de archivo, y sin fuga de información sobre el orden de subida (con v4) o listado cronológico fácil (con v7).

IDs de correlación para rastreo distribuido

Genera un UUID en el punto de entrada de una petición, pásalo a través de todos los microservicios en las cabeceras. Cuando algo se rompe, grep todos los logs para ese UUID para ver la ruta completa de la solicitud. v4 es ideal aquí — no necesitas ordenamiento, solo unicidad.

Lo Que Hay Que Saber

1.

Los UUIDs v4 son terribles como claves primarias (usa v7)

Los UUIDs v4 aleatorios causan fragmentación del índice B-tree porque las inserciones aterrizan en posiciones aleatorias. Más divisiones de páginas, más E/S de disco y escrituras más lentas. Los benchmarks muestran que los UUIDs v7 dan 2-3x mejor rendimiento de inserción en PostgreSQL. Si ya usas v4, no puedes migrar fácilmente — pero para tablas nuevas, usa v7.

2.

Los UUIDs no son secretos

Un UUID es un identificador, no un token de seguridad. Los UUIDs v7 filtran la hora de creación (la marca de tiempo está en los primeros 48 bits). Los UUIDs v4 son aleatorios pero solo tienen 122 bits de entropía — bien para unicidad, no para tokens sensibles. Para claves API o tokens de sesión que deban resistir fuerza bruta, usa valores aleatorios de 256 bits.

3.

Almacenar como binary(16), no varchar(36)

Un UUID como texto tiene 36 caracteres (con guiones). Como binario, son 16 bytes — menos de la mitad del almacenamiento. PostgreSQL tiene un tipo UUID nativo (16 bytes). BINARY(16) de MySQL con UUID_TO_BIN() funciona bien. Esto importa cuando tienes millones de filas con claves foráneas UUID.

4.

No elimines los guiones a menos que sea necesario

El formato estándar es 8-4-4-4-12 con guiones. Algunos sistemas los eliminan (32 caracteres hex). Ambos son válidos, pero los guiones hacen los UUIDs más legibles y el dígito de versión (posición 13) más fácil de detectar. Mantén los guiones a menos que un sistema requiera explícitamente su eliminación.

Ejemplos

UUID v4 — puro aleatorio

Nota el "4" en la posición 13 (versión) y 8/9/a/b en la posición 17 (variante).

Input

Versión: v4

Output

f47ac10b-58cc-4372-a567-0e02b2c3d479

UUID v7 — ordenable por tiempo

Nota el "7" en la posición 13. Los primeros 12 caracteres hex codifican la marca de tiempo Unix en milisegundos.

Input

Versión: v7

Output

018f6b2d-3c4a-7b12-9f8e-1a2b3c4d5e6f

Características

  • UUID v4: 122 bits de aleatoriedad criptográfica vía crypto.randomUUID()
  • UUID v7: marca de tiempo con precisión de milisegundos + bits aleatorios (RFC 9562)
  • Generación en lote: hasta 100 UUIDs con un clic
  • Formato estándar 8-4-4-4-12 con hexadecimal en minúsculas
  • Copia con un clic para UUIDs individuales o todos
  • Funciona 100% en tu navegador — cero peticiones de red

Preguntas Frecuentes

¿Colisionarán alguna vez dos UUIDs?

Para v4: la probabilidad es de 1 entre 2^122 (aproximadamente 5,3 × 10^36). Habría que generar mil millones de UUIDs por segundo durante 85 años para alcanzar una probabilidad de colisión del 50%. En cualquier sistema real, no ocurrirá. Para v7: riesgo de colisión aún menor porque la marca de tiempo garantiza que UUIDs generados en milisegundos diferentes nunca colisionen.

¿Debo usar UUID v4 o v7 para mi base de datos?

v7, casi siempre. Los UUIDs v4 aleatorios causan fragmentación del índice B-tree — las inserciones aterrizan en posiciones aleatorias, causando divisiones de página y degradando el rendimiento de escritura. Los UUIDs v7 están ordenados por tiempo, así que las inserciones siempre se añaden al final del índice. Benchmarks de PostgreSQL muestran 2-3x mejor rendimiento de inserción con v7. La única razón para usar v4 es si necesitas ocultar explícitamente el orden de creación.

¿Se puede extraer la marca de tiempo de un UUID v7?

Sí. Los primeros 48 bits de un UUID v7 son la marca de tiempo Unix en milisegundos. No está cifrada ni oculta. Si la hora de creación es información sensible en tu caso, usa v4. Para la mayoría de aplicaciones (IDs de base de datos, logs de eventos), exponer la hora de creación está bien y es útil.

UUID vs ULID vs nanoid — ¿cuál debo usar?

UUID v7 y ULID resuelven el mismo problema (IDs únicos ordenables por tiempo) pero UUID v7 es ahora un estándar RFC oficial (9562). nanoid es más corto (21 caracteres vs 36) pero no es un estándar — bueno para URL slugs, no para PKs de bases de datos. Si necesitas interoperabilidad y cumplimiento de estándares, usa UUID v7. Si necesitas IDs cortos para URLs, usa nanoid.

¿Cómo almacenar UUIDs eficientemente en una base de datos?

Usa el tipo UUID nativo de la base de datos si está disponible (PostgreSQL tiene uno, 16 bytes). En MySQL, usa BINARY(16) con UUID_TO_BIN(uuid, 1) — la bandera swap reordena bytes para mejor rendimiento de índice con v1/v7. Nunca almacenes como VARCHAR(36) en tablas de gran volumen — desperdicia almacenamiento y ralentiza comparaciones. Con millones de filas, la diferencia es apreciable.

Consejos y flujos de trabajo relacionados