Generador de UUID v7

Genera valores UUID v7 online: UUID ordenables por tiempo con timestamp de 48 bits en milisegundos y 74 bits aleatorios.

Formato
ID generados
Listo. Genera valores UUID v7 en tu navegador.

Cómo se construye este ID

Estructura
Timestamp Unix de 48 bits en milisegundos, bits de versión 7, bits de variante RFC y relleno aleatorio.
Entropía
74 bits aleatorios en esta implementación; no hay contador monotónico.
Tiempo
Sí. Los primeros 48 bits codifican el momento de creación, así que los IDs se ordenan por tiempo entre milisegundos distintos.
Riesgo de colisión
Dentro de un mismo milisegundo, las colisiones dependen de 74 bits aleatorios; para volúmenes extremos conviene un servicio coordinado.
Ejemplo
01a044bc-582d-7f34-8fab-6671d9ef477d

Tus ID se generan localmente con aleatoriedad fuerte del navegador. No se envía nada a BroBroGo.

Preguntas frecuentes

¿Por qué elegir UUID v7 en vez de UUID v4?

UUID v7 conserva la forma UUID pero se ordena por tiempo, útil para logs, índices de base de datos y flujos de eventos casi cronológicos.

¿UUID v7 oculta la hora de creación?

No. El timestamp forma parte del ID. Usa UUID v4 o NanoID si necesitas un identificador opaco sin datos de tiempo.

Cómo funciona el UUID v7: marca de tiempo y aleatoriedad

El UUID v7 es un identificador de 128 bits que se representa como una cadena de 36 caracteres en el formato estándar xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Su rasgo distintivo es que los primeros 48 bits contienen una marca de tiempo Unix en milisegundos. A continuación, los 74 bits restantes son aleatorios (con unos pocos bits reservados para la versión y variante). Esta combinación permite que los IDs generados sean cronológicamente ordenables y, al mismo tiempo, criptográficamente difíciles de adivinar.

La herramienta genera estos IDs localmente en el navegador, sin enviar ningún dato a BroBroGo. Utiliza la API crypto.getRandomValues() del navegador para obtener aleatoriedad fuerte. Cuando seleccionas una cantidad entre 1 y 100, la página produce esa misma cantidad de UUID v7, todos incrustando la marca de tiempo del momento exacto de generación. Cualquier cambio en las opciones —contador, uso de mayúsculas o inclusión de guiones— provoca una regeneración inmediata.

El estándar UUID v7 está definido en el borrador RFC 9562 (antes RFC 4122 bis). A diferencia de UUID v4, que es completamente aleatorio, v7 sacrifica una parte de la entropía para ganar orden temporal. En concreto, de los 128 bits, 48 son la marca de tiempo y el resto son aleatorios. Esto da un espacio de 2^80 valores aleatorios, más que suficiente para evitar colisiones incluso en sistemas de alta concurrencia.

Ordenación temporal y sus límites: qué ocurre en el mismo milisegundo

Por cómo está diseñado, dos UUID v7 generados en milisegundos diferentes se ordenan correctamente por su momento de creación. El primero en tiempo tendrá una marca de tiempo menor y, por tanto, aparecerá antes en una ordenación lexicográfica. Esto resuelve el problema de localidad de índice que afecta a UUID v4: cuando se usan como clave primaria en una base de datos B-tree, los UUID v7 se insertan cerca unos de otros, reduciendo la fragmentación y mejorando el rendimiento.

Sin embargo, el propio estándar no garantiza un orden estricto entre identificadores generados dentro del mismo milisegundo. En ese lapso, el orden depende únicamente de la parte aleatoria. Si dos IDs se crean en el mismo milisegundo, no se puede saber cuál fue primero. Esto es intencionado: permite una mayor paralelización, ya que cada generador puede usar su propia fuente de aleatoriedad sin necesidad de coordinación. En sistemas distribuidos donde varios nodos generan IDs a la vez, esa relajación evita cuellos de botella.

La herramienta refleja esta limitación: los UUID v7 que ves en una misma generación (dentro del mismo clic) pueden no estar estrictamente ordenados entre sí si varias solicitudes ocurrieran en el mismo instante, pero como el navegador genera todos en serie bajo un solo hilo, dentro de una misma petición suelen caer en el mismo milisegundo y aparecen desordenados. Es un comportamiento esperado, no un error.

Comparación con UUID v4: por qué migrar a v7 mejora el rendimiento en bases de datos

Aspecto UUID v4 UUID v7
Estructura 122 bits aleatorios + 6 bits de versión y variante 48 bits de marca de tiempo + 74 bits aleatorios + 6 bits fijos
Ordenación cronológica No Sí, por milisegundo
Localidad de índice Mala; inserciones aleatorias fragmentan el B-tree Buena; inserciones cercanas en tiempo
Colisiones Extremadamente raras (2^122) Muy raras (2^74 de aleatoriedad)
Longitud en texto 36 caracteres (con guiones) 36 caracteres (con guiones)

La principal ventaja de UUID v7 frente a v4 es la localidad de índice. En bases de datos como PostgreSQL o MySQL, las claves primarias aleatorias (v4) provocan que cada nueva inserción tenga que buscar un lugar distinto en el árbol, causando división de páginas y escritura en disco fragmentada. Con v7, las inserciones se concentran en la parte más reciente del índice, mejorando la eficiencia del caché y reduciendo la contención de bloqueos.

Además, el componente de tiempo permite ordenar registros por fecha de creación sin necesidad de una columna adicional created_at. Basta con ordenar por el UUID. Esto simplifica consultas y puede ahorrar espacio en índices compuestos.

Personalización de la salida: mayúsculas, guiones y cantidad

La página ofrece tres controles para adaptar el formato de los identificadores a las necesidades de cada proyecto:

  • Cantidad (Count): un número entero entre 1 y 100, ambos inclusive. La herramienta genera exactamente esa cantidad de UUID v7.
  • Mayúsculas (Uppercase): al activarlo, todas las letras hexadecimales (a‑f) se convierten a mayúsculas. Por defecto, se generan en minúsculas. Esto solo afecta a la representación; el valor subyacente es el mismo.
  • Incluir guiones (Include hyphens): al desactivarlo, se eliminan los guiones que separan las secciones del UUID, quedando una cadena continua de 32 caracteres hexadecimales. Algunos sistemas de almacenamiento prefieren el formato sin guiones para ahorrar espacio o simplificar el parseo.

Es importante notar que la presencia o ausencia de guiones no altera el valor del identificador; solo su representación textual. La norma RFC 4122 recomienda el formato canónico con guiones, pero muchas implementaciones aceptan ambas formas. La herramienta te permite elegir según el contexto de uso.

Al hacer clic sobre un ID individual, este se copia al portapapeles. Si usas el botón de copiado masivo, se copian todos los IDs separados por saltos de línea y el estado muestra “¡Copiados todos!”. Tras la generación, el estado cambia a “Generado” y, si no se toca ningún control, permanece en “Listo”.

Casos de uso en sistemas distribuidos y bases de datos

  • Claves primarias en tablas con alta carga de escritura: en un sistema de registro de eventos o una cola de mensajes, los UUID v7 evitan la fragmentación del índice y permiten consultas eficientes por rango de tiempo.
  • Auditoría y trazas: al llevar la marca de tiempo en el propio ID, no hace falta una columna separada para saber cuándo se creó un registro. Esto simplifica las consultas de depuración.
  • Identificadores públicos: a diferencia de un contador secuencial (como un autoincrement), el UUID v7 no revela la cantidad total de registros ni permite adivinar IDs vecinos. Es adecuado para exponer en URLs o APIs.
  • Migración desde UUID v4: cambiar a v7 es sencillo porque comparte el mismo formato de 36 caracteres. Los sistemas existentes que ya manejan UUIDs pueden sustituir la generación sin modificar esquemas de tabla.
  • Sistemas offline o con conectividad intermitente: al generar los IDs localmente (en el navegador o en el dispositivo), no se necesita un servidor central, lo que permite trabajar sin conexión y sincronizar después.

Preguntas frecuentes (FAQ)

¿Puedo usar UUID v7 como clave primaria en cualquier base de datos relacional? Sí, siempre que la base de datos acepte cadenas de 36 caracteres como clave. En bases como PostgreSQL, MySQL o SQL Server, es una práctica común. Además, la ordenación por milisegundo mejora el rendimiento frente a UUID v4.

¿Qué ocurre si dos usuarios generan UUID v7 en el mismo milisegundo? ¿Chocan? La probabilidad de colisión es extremadamente baja porque, además de la marca de tiempo, hay 74 bits aleatorios (unos 18 cuatrillones de posibilidades). Incluso si dos generadores distintos toman el mismo milisegundo, es casi seguro que los bits aleatorios serán diferentes.

¿Por qué los UUID v7 generados en la misma ejecución no aparecen estrictamente ordenados? Porque todos se generan dentro del mismo milisegundo (el tiempo de ejecución del script es inferior a 1 ms). Por tanto, la parte de marca de tiempo es idéntica y el orden viene dado por la aleatoriedad, que no guarda relación con el instante real de creación dentro de ese milisegundo.

¿Es seguro compartir UUID v7 públicamente (en URLs, por ejemplo)? Sí, en el sentido de que no revelan información sensible más allá del momento de creación (con precisión de milisegundo). Si ese dato es crítico para tu privacidad, considera que expones la fecha y hora de generación. Por lo demás, la parte aleatoria impide que alguien pueda adivinar otros IDs.

¿Puedo generar más de 100 UUID v7 a la vez? La herramienta limita el contador a 100 unidades por razones prácticas de interfaz y para evitar congelar el navegador. Si necesitas más, puedes hacer varias tandas.

¿Se almacenan los UUID generados en el servidor de BroBroGo? No. Todo el proceso ocurre en tu navegador. La página no envía ningún dato al servidor, ni los IDs ni las opciones seleccionadas. La generación es completamente local usando la API criptográfica del navegador.