Decodificador de UUID

Qué hay dentro de un UUID

Un UUID son 128 bits, escritos normalmente como 32 dígitos hexadecimales en cinco grupos separados por guiones. La mayoría de esos bits cambian según la versión, pero seis no cambian nunca: cuatro deletrean la versión y dos marcan la variante. Por eso todo UUID de versión 4 empieza su tercer grupo con un 4 literal, y por eso el cuarto grupo casi siempre empieza por 8, 9, a o b.

Esos seis bits son los que lee esta página. La versión te dice cómo se hizo el UUID —a partir de azar, de un nombre con hash o de un reloj— y por tanto qué más puedes averiguar de él. La variante te dice qué disposición sigue, y eso importa porque dos de las cuatro variantes son anteriores al estándar que usa todo el mundo.

La especificación vigente es el RFC 9562, publicado en mayo de 2024, y sustituyó por completo al RFC 4122. Añadió las versiones 6, 7 y 8 y el UUID máximo, así que un decodificador escrito antes de esa fecha ni siquiera reconoce un UUID de versión 7, que es justo el que cada vez se usa más para claves nuevas de base de datos.

Cómo se usa

1. Pega el UUID. Con guiones, en hexadecimal a secas, entre llaves o con el prefijo urn:uuid: — se aceptan las cuatro formas, y da igual mayúsculas o minúsculas.
2. Lee la versión y la variante. Cada una viene explicada, no solo nombrada, incluido lo que implica sobre de dónde salieron los bits. Las versiones nuevas del RFC 9562 van marcadas.
3. Comprueba si lleva hora. Las versiones 1, 6 y 7 codifican un instante, y la herramienta lo descodifica exacto. Las demás no llevan ninguno, y la herramienta lo dice en vez de enseñarte un número.

El reloj que empieza en 1582

Los UUID de versión 1 llevan una marca de tiempo de 60 bits, y la especificación la define como un recuento de intervalos de 100 nanosegundos desde las 00:00:00,00 del 15 de octubre de 1582, el día en que entró en vigor el calendario gregoriano. Un UUID generado esta mañana está contando desde el siglo XVI, en diezmillonésimas de segundo.

No es una rareza que alguien detectara después: el propio RFC es crítico con ello. Al explicar por qué existe la versión 7, califica esa época de poco común y difícil de representar con exactitud en un formato numérico estándar, y la queja es justa: 60 bits de pulsos de cien nanosegundos no caben en el número en coma flotante que casi todos los lenguajes te dan por defecto. Esta página lleva la cuenta como un entero exacto y convierte una sola vez, al final.

La versión 6 es el mismo reloj con los campos reordenados para que la parte más significativa vaya primero, lo que hace que los UUID se ordenen cronológicamente como simples cadenas. La versión 7 abandona la época gregoriana por completo y guarda milisegundos Unix corrientes en los primeros 48 bits. Los tres UUID de ejemplo de la propia especificación codifican el mismo instante, y descodificarlos aquí da la misma respuesta tres veces.

La versión 7 le cuenta a todo el mundo cuándo se creó

La versión 7 es hoy la recomendación habitual para claves primarias de base de datos, y el motivo es real: como la marca de tiempo va delante, los identificadores se ordenan por instante de creación, así que se insertan al final de un índice en vez de esparcirse por él. Eso arregla un problema de rendimiento auténtico que provocan las claves aleatorias de versión 4.

Lo que se dice mucho menos es la otra consecuencia. La hora de creación no se guarda al lado del identificador: es los primeros 48 bits del identificador, y no hay ajuste que lo desactive. Cualquiera que vea un UUID de versión 7 sabe el milisegundo en que se generó. Si esos identificadores aparecen en URL, en respuestas de API, en tickets de soporte o en cualquier cosa que vea un cliente, has publicado tus marcas de creación y, con dos de ellas, el intervalo entre dos eventos.

A menudo eso es inofensivo y a veces no lo es: unas claves de aspecto secuencial permiten a alguien de fuera estimar cuántos registros creas por hora, y una hora de creación filtrada puede bastar para correlacionar un registro anónimo con un suceso conocido. Es una razón para pensar por dónde viaja el identificador, no para evitar la versión 7, pero debería ser una decisión y no una sorpresa.

La versión 4, en cambio, no lleva nada dentro. 122 de sus 128 bits son aleatorios y los otros seis son los marcadores fijos de versión y variante, así que un UUID de versión 4 solo revela que es un UUID de versión 4. Si un decodificador te enseña una fecha para uno, se la ha inventado.

Lo que esto no te dice

No te dice si el UUID es real. Cualesquiera 32 dígitos hexadecimales con los seis bits adecuados en su sitio se descodifican a la perfección, los haya generado algo o no. La comprobación es estructural, no existencial.

En la versión 1 descodifica la hora pero no dice nada del campo de nodo, que en el diseño original era la dirección de la tarjeta de red de la máquina. Precisamente por eso cayó en desuso la versión 1 para cualquier cosa pública, y devolver ese dato no es un servicio que merezca la pena ofrecer.

Las versiones 3 y 5 son hashes de un nombre dentro de un espacio de nombres, y los hashes no van hacia atrás: el UUID se deriva de la entrada, pero la entrada no se recupera del UUID. Y la versión 8 está deliberadamente sin especificar: el estándar define solo sus bits de versión y variante y calla sobre el resto, así que no hay nada más que descodificar de lo que ya enseña esta página.

¿Por qué es gratis?

Son desplazamientos de bits sobre 128 bits, ejecutándose en tu navegador. No hay consulta, ni servidor, ni cuenta.

Nada de lo que pegas se sube, se guarda ni se registra, y aquí importa: un UUID de tu propio sistema es el identificador de uno de tus registros. No sale nunca de la pestaña.