Generador UUID v4
Genera UUID v4 aleatorios con seguridad criptográfica
…
Formatear
UUID v4 es la versión de UUID más ampliamente utilizada en el software moderno. A diferencia de sus variantes que derivan bits de una marca de tiempo o de un hash de espacio de nombres, UUID v4 está construido enteramente a partir de datos aleatorios, lo que lo convierte en la opción más sencilla y portable cuando se necesita un identificador único que no lleva metadatos sobre su origen.
Este generador usa crypto.randomUUID(), la API nativa del navegador y Node.js, que obtiene entropía del generador de números aleatorios criptográficamente seguro del sistema operativo, el mismo origen usado para el material de claves TLS.
¿Qué es UUID v4?
Un Identificador Universalmente Único (UUID) es una etiqueta de 128 bits estandarizada en RFC 4122. Generalmente se representa como 32 dígitos hexadecimales agrupados por guiones en el patrón 8-4-4-4-12:
En UUID v4, 122 de los 128 bits son aleatorios. Los 6 bits restantes son campos fijos requeridos por la especificación: 4 bits codifican la versión (0100 = 4) y 2 bits codifican la variante RFC 4122 (10). Esos bits fijos son la razón por la que el tercer grupo siempre comienza con 4 y el cuarto grupo siempre comienza con 8, 9, a o b.
Anatomía de un UUID v4
Desglose de 550e8400-e29b-41d4-a716-446655440000:
| Segmento | Bits | Significado |
|---|---|---|
| 550e8400 | 32 aleatorios | time_low (nombre histórico — completamente aleatorio en v4) |
| e29b | 16 aleatorios | time_mid (nombre histórico — completamente aleatorio en v4) |
| 41d4 | 4 fijos + 12 aleatorios | Nibble de versión 4 (binario 0100) + 12 bits aleatorios |
| a716 | 2 fijos + 14 aleatorios | Bits de variante 10 (MSBs del primer byte) + 14 bits aleatorios |
| 446655440000 | 48 aleatorios | node (completamente aleatorio en v4) |
8, 9, a o b, porque los dos bits más significativos de ese byte están fijos en 10 (el marcador de variante RFC 4122), dejando los dos bits restantes libres.UUID v4 vs Otras Versiones
RFC 4122 define cinco versiones de UUID. Cada una resuelve un problema diferente:
Combina una marca de tiempo de 60 bits (intervalos de 100 nanosegundos desde oct. 1582) con la dirección MAC del host. Monótonamente creciente dentro de una máquina.
Use when: necesita IDs ordenados por tiempo y no le importa revelar la identidad del servidor y el tiempo de generación.
Determinista: el mismo espacio de nombres + nombre siempre produce el mismo UUID. Usa hash MD5.
Use when: necesita IDs reproducibles a partir de un espacio de nombres conocido (p. ej. nombres DNS). Prefiera v5 sobre v3.
122 bits de aleatoriedad criptográficamente segura. Sin marca de tiempo, sin MAC, sin espacio de nombres. La elección de propósito general más común.
Use when: necesita IDs únicos sin significado estructural y máxima privacidad.
Como v3 pero usa SHA-1. Aún determinista a partir de espacio de nombres + nombre.
Use when: necesita identificadores reproducibles y dirigidos al contenido (p. ej. IDs estables para recursos identificados por URL).
Más reciente (RFC 9562, 2024). Codifica una marca de tiempo Unix en milisegundos en los bits más significativos, luego bits aleatorios. Ordenable y amigable para bases de datos.
Use when: necesita IDs amigables para índices de bases de datos con ordenación temporal natural (prefiera sobre v1 para proyectos nuevos).
Cuándo Usar UUID v4
UUID v4 es la herramienta correcta en la gran mayoría de situaciones donde simplemente necesita «un ID único» sin restricciones adicionales:
IDs de usuario y cuenta
IDs de usuario opacos que no revelan nada sobre el tiempo de creación de la cuenta ni la identidad del servidor. No pueden enumerarse ni adivinarse.
Claves primarias de base de datos
Funciona con cualquier motor de base de datos. UUID v4 es seguro para generar en el lado del cliente y fusionar desde fuentes distribuidas sin coordinación — sin tabla de secuencias ni servicio central de IDs.
IDs de sesión y token
122 bits de aleatoriedad hacen que la fuerza bruta sea computacionalmente inviable — comparable en fuerza a un token aleatorio de 122 bits.
Nombres de archivo y objeto
Nombres de archivo seguros para deduplicación en cargas, claves de objetos S3 o entradas de caché. Sin riesgo de que dos clientes escriban en la misma clave.
Claves de idempotencia
Genere un UUID en el cliente antes de enviar una solicitud. El servidor puede deduplicar de forma segura las solicitudes reintentadas sin un contador compartido.
IDs de correlación y trazabilidad
Adjunte un UUID a cada línea de registro y tramo de rastreo distribuido. No se necesita coordinación entre servicios o máquinas.
Probabilidad de Colisión
Con 122 bits aleatorios, el espacio de UUID v4 contiene 2122 ≈ 5,3 × 1036 valores posibles. La probabilidad de colisión sigue el problema del cumpleaños:
El punto de referencia comúnmente citado: para tener un 50% de probabilidad de una colisión, necesitaría generar aproximadamente 2,71 × 1018 UUIDs. A una tasa de 1 mil millones de UUIDs por segundo, eso tomaría aproximadamente 85 años de generación continua. Para cualquier aplicación del mundo real, las colisiones no son una preocupación práctica.
Ejemplos de Código
JavaScript — Navegador y Node.js 14.17+
El método crypto.randomUUID() está disponible de forma nativa en todos los navegadores modernos (Chrome 92+, Firefox 95+, Safari 15.4+) y en Node.js 14.17+. No se requiere instalación de paquetes.
// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"
// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())Node.js — versiones anteriores (paquete uuid)
const { v4: uuidv4 } = require('uuid')
const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"Python
import uuid # Generate a UUID v4 id = str(uuid.uuid4()) # → '110e8400-e29b-41d4-a716-446655440000' # The uuid module uses os.urandom() — cryptographically secure print(uuid.uuid4().hex) # without hyphens # → '110e8400e29b41d4a716446655440000'
Go
import "github.com/google/uuid" id := uuid.New().String() // → "110e8400-e29b-41d4-a716-446655440000" // Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic) // Always prefer github.com/google/uuid for production use
Rust
# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }use uuid::Uuid; let id = Uuid::new_v4().to_string(); // → "110e8400-e29b-41d4-a716-446655440000"
Preguntas Frecuentes
¿Es UUID v4 criptográficamente seguro?
UUID v4 en sí mismo no es una primitiva de seguridad — es un formato de identificador. Sin embargo, cuando se genera mediante crypto.randomUUID() (navegador o Node.js) o APIs equivalentes a nivel de SO, la entropía subyacente es criptográficamente segura. Esto significa que los valores UUID v4 son adecuados para usar como tokens de sesión o claves de idempotencia, donde la imprevisibilidad importa. No use generadores de UUID basados en Math.random() para contextos sensibles a la seguridad — use solo APIs que explícitamente provienen del CSPRNG del SO.
¿Pueden ser iguales dos UUID v4?
Teóricamente sí, pero prácticamente no. La probabilidad de generar un duplicado dentro de cualquier conjunto de datos realista (miles de millones de IDs) es astronómicamente pequeña — mucho menos probable que un fallo de hardware que cause corrupción de datos. La colisión de UUID v4 se trata como imposible en el diseño de sistemas de producción. Si genuinamente necesita una garantía de cero colisiones, use un contador centralizado o una secuencia de base de datos.
UUID v4 vs nanoid — ¿cuál debo usar?
Ambos son generadores de IDs aleatorios respaldados por un CSPRNG. Las diferencias clave:
- UUID v4 sigue el estándar RFC 4122, es reconocido por todas las bases de datos y frameworks, y no requiere dependencias (nativo
crypto.randomUUID()). - nanoid usa un alfabeto seguro para URL y es más corto por defecto (21 caracteres vs 36). Útil cuando importa la longitud de URL o la legibilidad. Requiere un paquete npm.
Prefiera UUID v4 cuando la interoperabilidad con sistemas externos importa (APIs, bases de datos, infraestructura de registro). Prefiera nanoid cuando quiera IDs más cortos y controle la pila completa.
¿Debo almacenar UUIDs como cadenas o binarios en bases de datos?
Para la mayoría de las bases de datos, almacenar como columna UUID o BINARY(16) (16 bytes) es más eficiente que una cadena VARCHAR(36) (36 bytes). PostgreSQL tiene un tipo nativo uuid. MySQL y MariaDB funcionan bien con BINARY(16) y los ayudantes UUID_TO_BIN() / BIN_TO_UUID(). Los usuarios de SQLite generalmente almacenan como TEXT. La elección de almacenamiento no afecta la unicidad ni la corrección.
¿Por qué UUID v4 tiene guiones — y puedo omitirlos?
Los guiones son parte de la representación canónica de UUID definida por RFC 4122. Son puramente cosméticos — no llevan información y no afectan el valor de 128 bits. Omitirlos le da una cadena hexadecimal compacta de 32 caracteres que es funcionalmente equivalente. La mayoría de los parsers de UUID aceptan ambas formas. En caso de duda, use la forma canónica con guiones para máxima compatibilidad con herramientas y bases de datos de terceros.
const id = crypto.randomUUID() // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '') // "550e8400e29b41d4a716446655440000"