Generador de UUID

Genera UUID y GUID gratuitos en versiones v1, v4, v5 y Nil. Produce identificadores unicos en lote, copia al portapapeles o descarga en segundos.

¿Tienes comentarios? Reporta errores, sugiere funciones o comparte tus ideas — leemos todos

Generador de UUID en linea

Herramienta para crear identificadores unicos universales (UUID/GUID) en distintas versiones. Genera uno o cientos con formato personalizado para usarlos en bases de datos, APIs, archivos y sistemas distribuidos.

¿Es UUID v4 verdaderamente único?

UUID v4 no está garantizado como único: es probabilísticamente único hasta el punto donde las colisiones no son una preocupación práctica. Un UUID v4 tiene 122 bits aleatorios (6 bits están reservados para los marcadores de versión y variante), dando 2^122 valores posibles (alrededor de 5,3 × 10^36). Por la paradoja del cumpleaños, necesitarías generar aproximadamente 2,71 quintillones de UUIDs para tener un 50% de probabilidad de una sola colisión: a mil millones por segundo, eso lleva 85 años. Para comparación, cada grano de arena en la Tierra es aproximadamente 7,5 × 10^18, así que el espacio UUID v4 es más de 10^17 veces más grande. La trampa es la calidad de tu fuente aleatoria: un PRNG débil (Math.random en lugar de crypto.getRandomValues) reduce drásticamente la entropía efectiva. Este generador usa la Web Crypto API para aleatoriedad de calidad criptográfica.

¿Qué versión de UUID debería usar: v1, v4, v6 o v7?

UUID v1 (marca de tiempo + dirección MAC, RFC 4122) está mayormente obsoleto porque filtra la MAC del host y revela el tiempo de creación. UUID v4 (aleatorio, RFC 4122) es la elección por defecto para identificadores generales: IDs que no deberían revelar nada. UUID v6 reordena los bytes de marca de tiempo de v1 para ser ordenables pero aún filtra la MAC. UUID v7 (RFC 9562, finalizado 2024) es el ganador moderno para claves primarias de bases de datos: los primeros 48 bits son una marca de tiempo Unix en milisegundos seguida de 74 bits aleatorios, así que los IDs v7 se ordenan cronológicamente y funcionan bien con índices B-tree mientras siguen siendo no adivinables. UUID v8 es una versión personalizada de forma libre reservada para diseños específicos de aplicación. Para nuevos sistemas en 2026, predetermina v7 para claves de bases de datos, v4 para cualquier cosa que no debería filtrar información.

¿Cuáles son los bits de versión y variante, y dónde están en el UUID?

Un UUID se representa como ocho-cuatro-cuatro-cuatro-doce dígitos hex (xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx). El primer nibble del tercer grupo (M) es la versión: 1, 4, 7, etc. Los primeros dos bits del cuarto grupo (N) codifican la variante: 10 en binario (así que el primer carácter es siempre 8, 9, a o b) marca UUIDs de RFC 4122 / RFC 9562. Por eso un UUID v4 válido siempre tiene el patrón xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. Una verificación rápida con regex rechaza IDs mal formados antes de que lleguen a tu base de datos. Los bits reservados cuestan seis en total —dejando 122 bits aleatorios en v4— y aseguran que UUIDs de diferentes especificaciones (la antigua variante GUID de Microsoft, versiones futuras) sean distinguibles sin ambigüedad.

¿Debería usar UUIDs como claves primarias en mi base de datos SQL?

Depende de la base de datos y la versión UUID. Los UUIDs v4 como claves primarias dañan significativamente el rendimiento de InnoDB y SQL Server: las posiciones de inserción aleatorias causan divisiones de página y fragmentación del índice agrupado, y el tamaño de 16 bytes duplica el almacenamiento de cada índice secundario versus un int de 4 bytes. PostgreSQL con el tipo uuid y un índice btree maneja v4 mejor pero aún pierde algunas ventajas de inserción secuencial. El prefijo monótonamente creciente de UUID v7 resuelve el problema de fragmentación: las inserciones se añaden al final del índice como un entero auto-incremental. Las ventajas de los UUIDs: globalmente únicos sin coordinación, seguros para fusionar bases de datos, sin ataques de enumeración en URLs /users/123, amigables con sistemas distribuidos. Para nuevos esquemas, predetermina UUID v7.

Generador de UUID — Genera UUID y GUID gratuitos en versiones v1, v4, v5 y Nil. Produce identificadores unicos en lote, copia al portapapele — **Generador de UUID**

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

Funcionalmente ninguna: "GUID" (Identificador Único Global) es el nombre de Microsoft para el mismo identificador de 128 bits definido en RFC 4122. El diseño de bytes codificados es idéntico: 16 bytes en bruto. La representación textual es la misma: ocho-cuatro-cuatro-cuatro-doce hex. La ligera diferencia histórica es el orden de bytes: el formato GUID heredado de Microsoft almacenaba los primeros tres campos en little-endian (Data1, Data2, Data3) en disco, mientras que RFC 4122 especifica big-endian (orden de bytes de red). Esto significa que un GUID binario exportado desde una API COM de Windows y leído como bytes en un sistema Unix aparecerá con bytes intercambiados en los primeros 8 bytes. Los sistemas modernos se normalizan en la representación textual hex. Para el tipo uniqueidentifier de Microsoft SQL Server, los bytes en disco todavía están en el orden heredado.

¿Puedo acortar un UUID para usar en URLs sin perder unicidad?

Sí: los 128 bits de un UUID pueden codificarse más compactamente que la forma hex de 36 caracteres (con guiones) cambiando alfabetos. UUID codificado en Base64 son 22 caracteres (24 con relleno), Base64 seguro para URL con relleno eliminado son 22 caracteres, y Base58 (sin caracteres confundibles como 0/O/l/I) son 22 caracteres. Crockford Base32 son 26 caracteres y es amigable para humanos. Todos estos son sin pérdida: el receptor decodifica de vuelta a los mismos 16 bytes. NUNCA cortes caracteres: eso destruye la garantía de unicidad. Un hash de 64 bits como FNV o xxHash desde el UUID da salida de 16 caracteres pero intercambia colisiones por longitud y ya no es un UUID. Alternativas como Nano ID o ULID dan amabilidad similar para URLs desde el inicio sin el paso de traducción UUID. ULID incluso usa Crockford Base32 ordenable por diseño.

¿Son los UUIDs criptográficamente seguros o aptos para tokens de seguridad?

UUID v4 generado desde un RNG criptográfico (Web Crypto, /dev/urandom, BCryptGenRandom) tiene 122 bits de entropía, que excede la directriz simétrica de 128 bits menos los 6 bits fijos de versión/variante. Eso es suficiente para tokens de sesión, enlaces de restablecimiento de contraseña y claves de idempotencia: comparable a una cadena aleatoria Base64 de 21 caracteres. La advertencia: UUIDs de bibliotecas de lenguajes más antiguas que dependen de Math.random o semillado basado en tiempo NO son criptográficamente seguros y han sido rotos en la práctica (ataques de predicción del siguiente UUID contra uniqid de PHP, java.util.UUID con semillas inseguras). Verifica que tu fuente use crypto.randomUUID (navegador/Node 19+), uuid.uuid4 respaldado por os.urandom (Python), o System.Security.Cryptography (.NET). Los UUIDs v1, v6 y v7 exponen marcas de tiempo y no deberían usarse como secretos.

¿Por qué mi UUID se ve como 00000000-0000-0000-0000-000000000000 y qué es el UUID nulo?

El UUID todo en ceros es el UUID nulo (RFC 4122 sección 4.1.7), reservado como centinela que significa "ausente" o "aún no asignado". Es el equivalente UUID de NULL, útil en bases de datos donde la columna es NOT NULL pero la fila aún no ha sido asignada con un identificador real. Su contraparte, el UUID máximo (todo Fs, ffffffff-ffff-ffff-ffff-ffffffffffff) fue formalizado en RFC 9562 como el límite superior universal: útil para consultas de rango y como el equivalente LSN en logs solo de adición. Ambos son UUIDs legales pero nunca aparecen como salida aleatoria: la probabilidad de generar cualquiera por accidente es 1 en 2^122, efectivamente cero. Si ves el UUID nulo en datos de producción, tu código muy probablemente falló en inicializar el valor antes de insertar: agrega una verificación defensiva y rastrea de vuelta al constructor.