Generador de UUID y GUID

UUID significa identificador único universal. Es un número de 128 bits, escrito como 32 dígitos hexadecimales agrupados 8-4-4-4-12, diseñado para que cualquiera pueda generar uno en cualquier momento sin coordinarse con nadie y seguir confiando en que nunca se había generado antes.

GUID significa identificador único global y es el término de Microsoft para un UUID. Los bits son idénticos y ambos son intercambiables. La única diferencia real es de convención: las herramientas de Microsoft suelen escribir un GUID en mayúsculas y entre llaves, como en {019A0C2E-7D51-7B8E-9F42-6AC3D0B81E77}. Activa Mayúsculas y Llaves arriba y esta página produce exactamente esa forma.

Desactiva el conmutador Guiones. Los guiones no llevan información alguna —son una convención de legibilidad de la forma canónica—, así que quitarlos deja los mismos 32 dígitos hexadecimales y los mismos 128 bits. La forma de 32 caracteres es habitual en URL, nombres de archivo y columnas compactas de base de datos, y el decodificador de esta página la lee sin problema.

Un v4 son 122 bits aleatorios y nada más, así que dos v4 creados con un segundo de diferencia no guardan relación. Un v7 gasta los primeros 48 bits en una marca de tiempo Unix en milisegundos y llena los 74 restantes con aleatoriedad, de modo que los valores v7 ordenan por fecha de creación como simples cadenas. Eso importa en las claves primarias: las claves aleatorias dispersan las inserciones por todo un índice B-tree, mientras que las ordenadas por tiempo se añaden al final. Ambos son de 128 bits y ambos son únicos en la práctica.

En esta página sí, para v6, v7 y ULID. Vale la pena preguntarlo, porque una implementación ingenua falla justo aquí: una marca de tiempo solo avanza cada milisegundo, así que un lote de mil generado dentro de un mismo milisegundo comparte marca y queda ordenado únicamente por sus bits aleatorios, es decir, sin orden. El RFC 9562 §6.2 trata esto directamente y pide a las implementaciones que añadan un contador. Esta página usa el método Monotonic Random del RFC, en el que los bits posteriores a la marca son un contador de semilla aleatoria que avanza una cantidad aleatoria por cada ID del mismo milisegundo.

Usa v4 para un valor único de uso general. Usa v7 para todo lo que acabe siendo clave primaria o clave de orden. Usa v6 en lugar de v7 cuando un sistema ya esté construido sobre v1 y necesites claves ordenables sin cambiar el diseño de campos. Usa v5 cuando el identificador deba ser reproducible a partir de un nombre. v1 solo merece la pena por compatibilidad con algo que ya lo espera, y v3 solo donde MD5 sea ya el hash acordado: v5 es la misma idea con SHA-1.

La versión 6 llegó con el RFC 9562 en 2024 y es una versión 1 con la marca de tiempo reordenada. Un v1 guarda primero la parte menos significativa de la marca, y por eso los valores v1 no ordenan; un v6 guarda primero la más significativa, y por eso sí lo hacen. Todo lo demás —la secuencia de reloj, el campo de nodo, los anchos de campo— no cambia, así que v6 encaja en un sistema que ya guarda UUID v1. La mayoría de generadores son anteriores al RFC y sencillamente nunca lo añadieron. Este lo genera y lo decodifica.

Para un v4 la respuesta es que prácticamente no, y la cifra se deriva en vez de repetirse de oídas. Un v4 lleva 122 bits aleatorios, y la paradoja del cumpleaños sitúa la probabilidad del 50 % de una sola colisión en torno a 1,1774 × la raíz cuadrada de 2 elevado a 122, es decir, unos 2,7 trillones de UUID. Generando mil millones por segundo, llegarías ahí en unos 86 años. Las cifras desarrolladas aparecen bajo los resultados para el esquema que elijas, incluidos los NanoID cortos, donde el número cae en picado.

La aleatoriedad procede de la Web Crypto API, que es una fuente criptográficamente segura, no Math.random. Dicho eso, único no es lo mismo que impredecible, y para algunos tipos de UUID la pregunta está mal planteada. Un v1 o un v6 expone el instante en que se creó y un valor de nodo. Un v7 expone su milisegundo de creación por diseño. Un v3 o un v5 es el hash de unas entradas que alguien podría adivinar. Si un valor tiene que ser impredecible —un token de sesión, un enlace de restablecimiento de contraseña— usa v4 o un NanoID largo, y nunca una versión basada en tiempo.

Desde esta página, no. El campo de nodo de un v1 era originalmente la dirección MAC de la máquina, que es justamente por lo que v1 cayó en desgracia. El RFC 9562 §6.10 permite usar un nodo aleatorio y exige poner a uno el bit menos significativo de su primer byte —el bit de multidifusión, que una tarjeta de red real nunca tiene—, de modo que un nodo aleatorio nunca puede confundirse con uno real. Esta página sortea un nodo aleatorio una vez por visita y lo usa para todos los v1 y v6 que generes, que es lo que haría una sola máquina.

No. El RFC 9562, publicado en mayo de 2024, deja obsoleto al RFC 4122. Mantiene sin cambios las versiones 1 a 5, añade las versiones 6, 7 y 8, define el UUID Max junto al ya existente UUID Nil y da las indicaciones sobre monotonía en lotes que esta página implementa. Varios generadores conocidos siguen describiéndose como herramientas RFC 4122, lo que es una forma práctica de saber si se han actualizado desde 2024.

El UUID Nil son los 128 bits a cero y significa «sin identificador»: es el valor que guardar cuando una columna necesita un UUID y realmente no hay ninguno. El UUID Max, los 128 bits a uno, lo añadió el RFC 9562 como el centinela opuesto: ordena por encima de cualquier otro UUID, lo que lo hace útil como límite superior exclusivo en una consulta por rango. Ninguno se genera; ambos son constantes.

Un ULID son 26 caracteres en base32 Crockford que guardan una marca de tiempo de 48 bits en milisegundos y 80 bits aleatorios. Ordena por tiempo como un v7 y es diez caracteres más corto que un UUID, a costa de no ser un UUID: cualquier cosa que espere una columna de tipo uuid lo rechazará. Un NanoID es un token aleatorio simple de un alfabeto de 64 símbolos seguro para URL, con la longitud que decidas; los 21 caracteres por defecto llevan 126 bits, algo más que un v4. Elige ULID cuando quieras algo ordenable y compacto, NanoID cuando lo quieras corto y público, y un UUID cuando algo aguas abajo espere el formato estándar.

Porque no puede, y ninguna otra herramienta tampoco. Un UUID lleva un nibble de versión y unos bits de variante, y un ULID tiene una longitud y un alfabeto que lo fijan: eso son estructuras que un decodificador puede leer. Un NanoID no tiene ninguna: son solo caracteres de un alfabeto de 64 símbolos, así que un NanoID, un token de sesión y una palabra corriente son indistinguibles a simple vista. Por eso el decodificador informa de la longitud y de la aleatoriedad máxima que cabría en esos caracteres, y se detiene antes de nombrar un formato. Solo el sistema que emitió el token puede validarlo.