Generación de UUID v4: algo más que un identificador aleatorio
Esta página genera uno o varios identificadores UUID versión 4 —cadenas de 36 caracteres en el formato hexadecimal estándar 8‑4‑4‑4‑12— y permite controlar el número de identificadores (hasta 100), si se muestran en mayúsculas o minúsculas y si incluyen guiones. El proceso ocurre íntegramente en el navegador, usando la aleatoriedad fuerte del sistema criptográfico. Se puede copiar un identificador individual o todos a la vez.
Lo que distingue a esta página de otros generadores es su enfoque en el UUID v4, que emplea 122 bits de aleatoriedad sin ningún tipo de sello temporal. Cada valor es esencialmente impredecible y la probabilidad de colisión es despreciable. A diferencia del UUID v7 o del ULID, los v4 se ordenan arbitrariamente: no llevan información temporal, lo que fragmenta los índices de base de datos cuando se usan como clave primaria. Además, la página permite alternar mayúsculas y guiones, pero la aleatoriedad interna y el formato son fijos. Por defecto, la salida es en minúsculas con guiones. Cualquier cambio en las opciones regenera todo el conjunto.
Cómo se genera un UUID v4: los 122 bits de aleatoriedad
Un UUID v4 ocupa 16 octetos (128 bits), pero de ellos, 6 bits son fijos según la especificación RFC 4122: los cuatro bits más significativos del séptimo octeto indican la versión (0100 para v4) y los dos bits más significativos del noveno octeto indican la variante (10). Los 122 bits restantes son aleatorios. En la práctica, el navegador obtiene esos bits mediante crypto.getRandomValues(), que es una fuente de aleatoriedad criptográficamente segura. El algoritmo toma un array de 16 bytes, aplica las máscaras necesarias para fijar los bits de versión y variante, y convierte cada byte en dos caracteres hexadecimales. Finalmente, si los guiones están activados, se insertan en las posiciones 8, 12, 16 y 20 para formar la representación estándar.
La longitud final de 36 caracteres se descompone así: 32 dígitos hexadecimales más 4 guiones (cuando estos están habilitados). Si se desactivan los guiones, la cadena tiene 32 caracteres. Al activar las mayúsculas, los dígitos hexadecimales se transforman con toUpperCase(), pero la representación interna sigue siendo la misma.
La probabilidad de colisión con dos UUID v4 generados independientemente es aproximadamente 2⁻¹²², un número tan pequeño que, incluso generando miles de millones, la probabilidad de que ocurra una coincidencia es inferior a la de un error cósmico. No obstante, el usuario debe saber que estos identificadores no tienen orden cronológico: si se usan como clave primaria en una base de datos, los nuevos insertos caerán en posiciones arbitrarias del índice, provocando fragmentación y pérdida de rendimiento.
Opciones de personalización: cantidad, mayúsculas y guiones
La página ofrece tres controles sobre la salida:
- Cantidad: un número entre 1 y 100. No se aceptan valores fuera de ese rango. Al superar los 100, el campo rechaza la entrada.
- Mayúsculas: un interruptor booleano, desactivado por defecto. Al activarlo, todos los dígitos hexadecimales se muestran en mayúsculas (A‑F), manteniendo el mismo orden de bits.
- Incluir guiones: activado por defecto. Si se desactiva, se eliminan los cuatro guiones y la salida es una cadena continua de 32 caracteres hexadecimales.
Cada cambio en cualquiera de estas opciones provoca una regeneración completa del conjunto de identificadores. Esto es intencionado: el usuario que modifica el número de identificadores espera obtener una nueva tanda, no reordenar los existentes.
La interfaz muestra, junto a la lista, un contador de identificadores generados (por ejemplo, «5 UUID»). También aparecen mensajes de estado: «Listo.» al cargar la página, «Generado.» después de crear los identificadores, y «¡Copiados todos!» tras usar el botón de copia masiva.
¿Para quién es útil y cuándo conviene evitarlo?
Los UUID v4 son ideales para:
- Tokens de seguridad y identificadores de sesión, donde la impredecibilidad es crítica.
- Claves externas que no se usan como índice primario en bases de datos relacionales.
- Datos de prueba o identificadores anonimizados en los que el orden temporal no importa.
- Identificadores de entidades en sistemas distribuidos donde no hay un coordinador central que asigne secuencias.
Sin embargo, no se recomiendan como clave primaria en tablas grandes con inserciones frecuentes. El índice agrupado (clustered index) de motores como InnoDB (MySQL) o SQL Server sufre al insertar filas cuyos valores de clave no son monótonos. Cada nuevo UUID v4 puede caer en cualquier lugar del árbol B+, provocando divisiones de página y fragmentación del índice. En esos casos, es preferible usar UUID v7 (ordenado por tiempo) o ULID, que combinan aleatoriedad con monotonicidad temporal.
Para el desarrollador que necesita generar un lote rápido de 100 UUID v4 sin depender de un servidor ni exponer datos a la red, esta página ofrece una solución inmediata. Todo el procesamiento ocurre en local: no se envía nada a ningún servidor, lo que garantiza privacidad y disponibilidad incluso sin conexión (una vez cargada la página).
Rendimiento en bases de datos: el problema del índice fragmentado
Un aspecto que a menudo se pasa por alto es el coste de usar UUID v4 como clave primaria en una base de datos relacional. Para ilustrarlo, comparemos UUID v4 con dos alternativas:
| Tipo de identificador | Bits de aleatoriedad | Orden temporal | Fragmentación de índice | Uso recomendado |
|---|---|---|---|---|
| UUID v4 | 122 | No | Alta | Claves externas, tokens |
| UUID v7 | 62 (tiempo) + 60 (aleatorio) | Sí (milisegundo) | Baja | Claves primarias |
| ULID | 48 (tiempo) + 80 (aleatorio) | Sí (milisegundo) | Baja | Claves primarias |
| ID secuencial | 0 (secuencia) | Sí | Mínima | Claves primarias pequeñas |
La tabla muestra que, aunque el UUID v4 ofrece la máxima impredecibilidad, paga un precio en rendimiento de escritura cuando se usa masivamente. En tablas pequeñas o con pocas inserciones, el impacto es irrelevante; pero en sistemas con millones de filas y alta concurrencia, la fragmentación puede degradar el rendimiento hasta un 30‑50 % en operaciones de escritura y lectura por índice.
El generador de esta página no interviene en ese debate: ofrece el formato tal como lo define el estándar, dejando al usuario la decisión de cuándo emplearlo. Por eso, los mensajes de estado y las opciones son simples, y la página se centra en hacer bien una sola tarea.
Preguntas frecuentes
¿Los UUID generados cumplen con la RFC 4122?
Sí. Se fijan los bits de versión (0100 en los bits 12‑15 del séptimo octeto) y variante (10 en los bits 6‑7 del noveno octeto). El resto son 122 bits aleatorios obtenidos del generador criptográfico del navegador.
¿Puedo usar estos UUID como clave primaria en PostgreSQL?
Sí, PostgreSQL acepta UUID como tipo nativo. Sin embargo, para tablas grandes con muchas inserciones, considera usar gen_random_uuid() (que genera UUID v4) o la extensión uuid-ossp con UUID v1‑v7. La página no limita su uso, pero advierte del posible impacto en el rendimiento.
¿Por qué al cambiar el número de identificadores se regeneran todos?
La página trata cada cambio de opciones como una nueva petición. Esto evita confusiones: si el usuario aumenta el contador, espera obtener identificadores nuevos, no mantener los anteriores y añadir más. Así se garantiza que todos los UUID de la lista sean distintos entre sí y coherentes con las opciones seleccionadas.
¿Se almacenan los UUID en algún servidor?
No. Todo el código se ejecuta en el navegador. La página no envía ningún dato a ningún servidor, ni siquiera de forma anónima. Los UUID se generan y permanecen exclusivamente en la memoria local hasta que el usuario los copia.
¿Qué ocurre si desactivo los guiones pero mantengo mayúsculas?
Se obtiene una cadena de 32 caracteres hexadecimales en mayúsculas, sin separadores. Por ejemplo: F47AC10B58CC4372A5670E02B2C3D479. La representación sigue siendo un UUID v4 válido, pero pierde la legibilidad del formato estándar.
¿Puedo generar más de 100 UUID a la vez?
El campo de cantidad acepta hasta 100 inclusive. Si necesita más, puede realizar varias tandas. La razón del límite es mantener la interfaz manejable y evitar un uso excesivo de memoria, especialmente en dispositivos con recursos limitados.