Generador UUID gratuito

Acerca de los UUID

Un UUID (identificador único universal) es un identificador de 128-bit diseñado para ser único en el espacio y en el tiempo. La versión más común, UUID v4, se genera con números aleatorios o pseudoaleatorios. El formato es 8-4-4-4-12 caracteres hexadecimales, por ejemplo 550e8400-e29b-41d4-a716-446655440000.

Una historia de cuatro décadas, de Apollo a RFC 9562

El concepto de UUID se originó en el Apollo Network Computing System (NCS) a mediados de los años 80, diseñado en Apollo Computer por Paul Leach y Rich Salz para soportar computación distribuida sin registro central. El formato fue adoptado por el Open Software Foundation Distributed Computing Environment (OSF DCE) en 1989 y estandarizado internacionalmente en 1995 como ITU-T X.667 / ISO/IEC 9834-8. La IETF dobló la spec en RFC 4122 (Leach, Mealling, Salz) en julio de 2005, que se convirtió en la referencia canónica durante dos décadas. RFC 4122 fue actualizada por RFC 9562 en mayo de 2024, que mantuvo todas las versiones originales (v1 a v5), añadió tres nuevas versiones (v6, v7, v8), y formalmente definió las constantes especiales «Nil UUID» (todos ceros) y «Max UUID» (todos unos). El linaje de versiones importa porque cada versión intercambia diferentes propiedades: basada en tiempo (ordenable, fugable); basada en nombre (determinista a partir de entradas); aleatoria (universal, opaca); personalizada (lo que necesites). La mejor práctica moderna para nuevas aplicaciones se ha desplazado de v4 (aleatoria) a v7 (timestamp + aleatorio) para claves primarias, mientras que v4 sigue siendo la respuesta correcta para identificadores opacos donde la ordenabilidad es indeseable.

Las ocho versiones, en lenguaje claro

• v1 (timestamp + dirección MAC). 60 bits de timestamp (intervalos de 100 nanosegundos desde la época gregoriana 1582) más la dirección MAC de la máquina de origen. La principal desventaja: filtra la dirección MAC de la máquina generadora, lo que es una preocupación de privacidad. El autor del virus Melissa fue famosamente identificado en 1999 en parte rastreando UUIDs v1 en documentos de Word hasta una máquina específica.
• v2 (DCE security). Variante de v1 que incluye un POSIX UID/GID. Casi nunca usada en la práctica; documentada por completitud.
• v3 (basada en nombre, MD5). UUID determinista derivado del hash MD5 de (UUID de namespace + cadena de nombre). Las mismas entradas siempre producen el mismo UUID, útil para traducir claves naturales (URLs, nombres de dominio, distinguished names) a forma UUID.
• v4 (aleatoria). 122 bits de aleatoriedad (los 6 bits restantes son tags de versión + variant). La versión más ampliamente usada, el por defecto que casi toda biblioteca «dame un UUID» retorna.
• v5 (basada en nombre, SHA-1). Igual que v3 pero usando SHA-1 en lugar de MD5. Preferida sobre v3 para nuevas aplicaciones porque SHA-1 está menos roto que MD5, aunque ambos tengan ataques de colisión conocidos.
• v6 (RFC 9562, mayo 2024, ordenada por tiempo). Reordena los bits de timestamp v1 para que la ordenación lexicográfica coincida con la cronológica. Resuelve la queja «v1 no se ordena por tiempo»; aún filtra la dirección MAC por defecto.
• v7 (RFC 9562, mayo 2024, timestamp Unix + aleatorio). Los primeros 48 bits son el timestamp Unix en milisegundos; los 74 bits restantes son aleatorios. Se ordena naturalmente por tiempo de creación, incluye datos de timestamp sin filtrar la identidad de la máquina, y es la recomendación moderna para claves primarias de base de datos. Postgres 18+ tiene uuidv7() incorporado; SQL Server tiene NEWSEQUENTIALID() con propiedades similares.
• v8 (personalizada). Reservada para diseños específicos de aplicación. El campo versión la marca como v8 y los bits de variant están establecidos correctamente; todo lo demás depende de la aplicación. Úsala cuando necesites incrustar tus propios datos estructurados en el sobre con forma de UUID.

Por qué v7 es cada vez más preferida sobre v4 para claves de base de datos

Las claves primarias aleatorias (UUIDs v4) tienen un coste de rendimiento bien documentado en bases de datos que organizan filas por clave primaria en un B-tree o índice similar. Cada nueva inserción aterriza en una posición aleatoria del índice, lo que fragmenta las páginas del índice, aumenta la amplificación de escritura en disco, y arruina la caché de páginas porque las filas insertadas recientemente están esparcidas a través de muchas páginas en lugar de agrupadas. Las claves secuenciales (enteros auto-incrementales, ULIDs, UUIDs v7) se insertan todas en el borde derecho del índice, lo que mantiene el working set pequeño y la amplificación de escritura mínima. La crítica del «anti-patrón de clave aleatoria» se remonta a la documentación temprana de SQL Server alrededor de NEWID versus NEWSEQUENTIALID, y ha sido rearticulada por la comunidad Postgres para v4 vs v7. El compromiso: v7 filtra el tiempo de creación de cada fila, lo que puede ser una preocupación de privacidad o fuga de información en algunas aplicaciones (p. ej., puedes decir cuándo se creó una cuenta leyendo su UUID). Para la mayoría de aplicaciones, la ganancia de rendimiento supera la fuga de timestamp; para aplicaciones de alta privacidad, v4 sigue siendo la respuesta correcta.

Probabilidad de colisión, las matemáticas del paradoja del cumpleaños

UUID v4 tiene 122 bits de aleatoriedad, dando aproximadamente 5,3 × 10³⁶ valores posibles. La paradoja del cumpleaños dice que necesitas aproximadamente la raíz cuadrada del tamaño del namespace para tener 50 % de probabilidad de cualquier colisión, unos 2,3 × 10¹⁸ UUIDs. Para ponerlo en términos humanos: si generas 1.000 millones de UUIDs por segundo continuamente, necesitarías unos 86 años para tener 50 % de probabilidad de una sola colisión. Para ratios de generación a escala de aplicación ordinaria (miles o millones por día), el riesgo práctico de colisión es cero. La causa más probable de «UUIDs duplicados» en sistemas reales es un generador con bug usando Math.random() en lugar de un CSPRNG, o un generador con entropía insuficiente al arranque, o un proceso que accidentalmente siembra dos generadores idénticamente, no las matemáticas subyacentes. Este generador usa crypto.randomUUID() del navegador (donde esté disponible) o crypto.getRandomValues(), ambos sacando del CSPRNG del sistema operativo (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes), la misma fuente de entropía usada para claves de sesión TLS.

Implementación en el navegador: crypto.randomUUID()

La API Web Crypto expone crypto.randomUUID() como un generador de una llamada que retorna una cadena UUID v4 conforme a RFC 4122. Llegó en Chrome 92 (julio 2021), Firefox 95 (diciembre 2021) y Safari 15.4 (marzo 2022), y ha estado disponible como baseline en todos los navegadores modernos desde aproximadamente 2022. Para navegadores más antiguos, el fallback estándar es asignar un Uint8Array de 16 bytes, llenarlo con crypto.getRandomValues(), establecer el nibble de versión a 4 (el nibble alto del 7º byte = 0x40), establecer los bits de variant a 10xxxxxx (los dos bits altos del 9º byte = 0x80), y formatear los bytes como cadena hex 8-4-4-4-12. Este generador usa crypto.randomUUID() cuando está presente y el fallback manual cuando no, la salida es idéntica de cualquier modo, solo ligeramente más lenta en la ruta de fallback. Ambas rutas corren enteramente en tu navegador; nada cruza la red.

Casos de uso, y qué necesita cada uno realmente

• Claves primarias de base de datos: especialmente sistemas distribuidos o sharded donde coordinar un contador entero es impractico. v7 es la recomendación moderna; v4 si necesitas opacidad de timestamp.
• IDs de correlación de peticiones API. Cada petición entrante recibe un UUID que viaja a través de cada servicio downstream en la cadena de llamadas; los logs de cualquier servicio pueden ligarse de vuelta a la petición de origen vía el ID. Stripe, Twilio y AWS X-Ray hacen todo esto.
• Claves de idempotencia para peticiones HTTP. El header Idempotency-Key de Stripe acepta un UUID; si el cliente reintenta la misma petición con la misma clave, Stripe devuelve la respuesta cacheada en lugar de cobrar la tarjeta dos veces. Este patrón es ahora estándar en APIs de pagos.
• Tokens de sesión, con salvedades. Un UUID v4 es criptográficamente aleatorio y tiene 122 bits de entropía, lo que es más que suficiente para un ID de sesión. Pero los tokens de sesión que son solo un UUID son vulnerables a ataques de enumeración si cualquier endpoint relacionado los filtra; la mejor práctica moderna es usar tokens más largos y firmados (JWT, Paseto) para estado de sesión.
• Nombres de archivo para deduplicación de subidas. Genera un UUID por cada subida, almacena el archivo en /uploads/{uuid}.ext: nunca tendrás colisión de nombre independientemente del nombre original, y no puedes accidentalmente servir el archivo de otro usuario adivinando la URL.
• IDs de mensaje en sistemas dirigidos por eventos. Kafka, RabbitMQ, AWS SQS y la mayoría de plataformas pub/sub recomiendan un UUID por mensaje para tracing y deduplicación; v7 es cada vez más el por defecto por la propiedad ordenable por timestamp.
• Generación de datos de prueba. Las bibliotecas Faker en cada lenguaje usan UUIDs como IDs por defecto para filas de prueba generadas.
• Identificadores de nodos de sistema distribuido. Un nuevo nodo arrancando en un cluster genera un UUID para sí mismo; el coordinador del cluster usa ese ID para enrutar tráfico e identificar el nodo en logs.

Alternativas que vale la pena conocer

UUID es el por defecto universal pero no la única opción, y varias alternativas valen la pena para casos de uso específicos. ULID (Universally Unique Lexicographically Sortable Identifier, Alex Knol, ~2016): 128 bits como UUID, pero codificado como 26 caracteres Crockford-Base32 en lugar de 32 dígitos hex, más compacto y URL-safe insensible a mayúsculas. Los primeros 48 bits son un timestamp Unix en milisegundos, así que los ULIDs se ordenan lexicográficamente por tiempo de creación. Conceptualmente muy cercano a UUID v7, precediéndolo por años. Snowflake (Twitter, 2010): 64 bits, mucho más pequeño que UUID, cabe en un BIGINT SQL. 41 bits de timestamp + 10 bits de ID de máquina + 12 bits de secuencia por milisegundo. Usado por Twitter/X, Discord, Instagram y muchos sistemas a gran escala donde las claves primarias de 64 bits son una restricción dura. KSUID (Segment, 2017): 27 caracteres, timestamp con precisión de segundo + 128 bits aleatorios. Intercambia precisión de milisegundo por una representación de cadena más pequeña que UUID. nanoid (Andrey Sitnik, 2017): una biblioteca diminuta que produce identificadores aleatorios URL-safe de longitud configurable. El por defecto de 21 caracteres proporciona resistencia a colisiones similar a UUID v4 en muchos menos bytes. Para una URL pública donde si no incrustarías un UUID, nanoid es más corto y amigable. El compromiso: los identificadores nanoid no tienen los bits marcadores de versión + variant que los distinguen como UUIDs, así que no encajan en sistemas que esperan valores con forma de UUID.

Seguridad de URL y variaciones de formato

Los UUIDs en su forma canónica con guiones (550e8400-e29b-41d4-a716-446655440000) son URL-safe, cada carácter (letras minúsculas, dígitos, guiones) está en el conjunto no reservado definido por RFC 3986. Esto significa que puedes soltar un UUID directamente en un path de URL o query string sin percent-encoding. Algunos sistemas eliminan los guiones por compactación, produciendo una cadena hex de 32 caracteres (550e8400e29b41d4a716446655440000) que sigue siendo URL-safe; la conversión es reversible porque la estructura UUID es fija. Algunos sistemas envuelven UUIDs en llaves ({550e8400-e29b-41d4-a716-446655440000}), la convención GUID de Microsoft; las llaves son decorativas y nunca viajan en URLs. Algunos sistemas ponen los caracteres hex en mayúsculas; los UUIDs son insensibles a mayúsculas según la spec, pero la consistencia dentro de un sistema importa. Este generador ofrece las tres opciones (mayúsculas, llaves, sin guiones) para compatibilidad con cualquier pipeline al que estés alimentando los UUIDs.

UUID vs GUID, Lo Mismo, Nombre Diferente

UUID es el término estándar usado por IETF, ISO y la mayoría de proyectos open-source. GUID (Globally Unique Identifier) es el término Microsoft usado en Windows, .NET, COM/OLE, SQL Server, Active Directory y el Registro de Windows. Ambos se refieren al identificador idéntico de 128 bits en el mismo formato hex 8-4-4-4-12. Funcionalmente intercambiables, un GUID generado por Windows puede usarse en cualquier lugar donde se espere un UUID, y viceversa. La única diferencia que vale la pena saber: la generación de GUID de Microsoft históricamente usó UUID v4 en muchas APIs pero UUID v1 (con dirección MAC) en algunos contextos COM/OLE más antiguos; está documentado en la especificación COM de Microsoft. Si recibes un GUID de un sistema de origen Microsoft y quieres saber qué versión es, comprueba el nibble de versión (el 13º carácter hex, '1' para v1, '4' para v4, etc.).

Privacidad: por qué el solo-navegador importa incluso aquí

Un UUID no tiene significado inherente, así que ¿por qué importa que el generador corra localmente? Dos razones. Primera, cuando un UUID se usa como token de sesión, clave de idempotencia o cualquier otro identificador tipo-secreto, generarlo en un servidor de terceros significa que ese servidor vio el valor antes de que tú lo usaras, una exposición pequeña pero real. Segunda, los generadores del lado del servidor que prometen «aleatoriedad criptográfica» no pueden ser verificados por el usuario; un servidor con bug o malicioso podría retornar valores no aleatorios que parecen aleatorios, y no tendrías forma de detectar el sesgo. Un generador solo-navegador ejecuta la misma llamada crypto.randomUUID() que tu aplicación ejecutaría en el lado del servidor; la entropía viene de la misma fuente del sistema operativo (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes); ningún tercero ve la salida. Puedes verificarlo abriendo la pestaña Network de DevTools mientras haces clic en Generar, no hay peticiones salientes. Pon la página offline (modo avión) tras cargar y el generador sigue funcionando.

Preguntas frecuentes

¿Cuál es la diferencia entre UUID y GUID?

Son esencialmente lo mismo. UUID es el término estándar (RFC 4122), mientras que GUID (identificador único global) es la terminología de Microsoft. Ambos se refieren a un identificador de 128-bit en el mismo formato hexadecimal 8-4-4-4-12.

¿Pueden dos UUID ser iguales alguna vez?

En teoría sí, pero la probabilidad es astronómicamente baja. UUID v4 tiene 122 bits aleatorios, lo que da aproximadamente 5.3 × 10³⁶ valores posibles. Habría que generar miles de millones de UUID por segundo durante décadas para tener una probabilidad del 50 % de una sola colisión.

¿Son estos UUID criptográficamente seguros?

Sí. Este generador utiliza la Web Crypto API (crypto.getRandomValues), que proporciona valores aleatorios criptográficamente fuertes. La salida es adecuada para casos de uso sensibles a la seguridad como tokens de sesión.

¿Debería usar UUID v4 o v7 para mi clave primaria de base de datos?

v7 es la recomendación moderna si tu base de datos lo soporta. v4 (aleatoria) inserta en posiciones aleatorias en índices B-tree, fragmenta el índice, y arruina la caché de páginas. v7 (timestamp + aleatorio, RFC 9562 mayo 2024) inserta en el borde derecho del índice porque los IDs se ordenan por tiempo de creación, mismo rendimiento de escritura que enteros auto-incrementales, con la distribución y unicidad de los UUIDs. Postgres 18+ tiene uuidv7() incorporado. El compromiso: v7 filtra el tiempo de creación de cada fila, lo que puede ser una preocupación de privacidad en algunas aplicaciones. Para la mayoría de casos de uso la ganancia de rendimiento supera la fuga de timestamp.

¿Qué son ULID, KSUID y nanoid?

Formatos de ID alternativos. ULID (Alex Knol, ~2016): 128 bits como UUID pero codificados como 26 caracteres Crockford-Base32; se ordena lexicográficamente por timestamp. KSUID (Segment, 2017): 27 caracteres, timestamp con precisión de segundo + 128 bits aleatorios. nanoid (Andrey Sitnik, 2017): biblioteca diminuta que produce IDs URL-safe aleatorios de longitud configurable; el por defecto de 21 caracteres da resistencia a colisiones similar a UUID v4 en muchos menos bytes. Snowflake (Twitter, 2010): IDs de 64 bits que caben en un BIGINT SQL, usados por Twitter, Discord e Instagram. Usa UUID cuando el sistema receptor espera formato UUID; usa las alternativas cuando tengas requisitos específicos de tamaño, ordenabilidad o amistad-de-URL.

¿Se envían los UUIDs a algún sitio?

No. Cada UUID se genera localmente en tu navegador usando la API Web Crypto. El generador nunca hace una petición de red, verifica en la pestaña Network de DevTools mientras haces clic en Generar, o pon la página offline después de cargar y confirma que la herramienta sigue funcionando. Seguro para generar tokens de sesión, claves de idempotencia u otros identificadores donde no quieras que un tercero haya visto el valor antes de usarlo.

Herramientas relacionadas