Un UUID permite que cualquier servidor, móvil o script cree un identificador sin consultar un contador central. Te contamos cómo leerlo, qué versión elegir, lo pequeña que es de verdad la probabilidad de colisión y su coste como clave primaria.
Un UUID (identificador único universal, por sus siglas en inglés) es un valor de 128 bits que cualquiera puede generar en cualquier sitio, sin consultar a una autoridad central, y que aun así puede tratarse como único. Escrito, son 32 dígitos hexadecimales en cinco grupos de 8-4-4-4-12 separados por guiones, como 7c4f1e2a-9b3d-4a6e-8f10-c2d5e7a9b341. Si te preguntas qué es un UUID en la práctica: es el formato estándar para que servidores, dispositivos o apps sin conexión creen identificadores por su cuenta sin pisarse. En el mundo Microsoft se le llama GUID.
Si necesitas unos cuantos ahora mismo, el generador de UUID crea entre 1 y 100 identificadores de la versión 4 en cada ejecución. Si en realidad buscas un secreto, como una clave de API o una contraseña, la herramienta adecuada es el generador de contraseñas. Para direcciones legibles tienes el generador de slug, y el formateador JSON te ayuda a revisar respuestas de API llenas de identificadores.
La especificación vigente es el RFC 9562, publicado en mayo de 2024, que sustituyó al veterano RFC 4122. Casi todos los bits transportan datos, pero dos campos pequeños ocupan siempre la misma posición y cuentan cómo se generó el valor:
| Posición | En el ejemplo | Significado |
|---|---|---|
| Primer dígito del tercer grupo | 4 en 4a6e | Versión: método de generación |
| Primer dígito del cuarto grupo | 8 en 8f10 | Variante: 8, 9, a o b indican el formato estándar |
| El resto | Bits aleatorios o basados en tiempo | Depende de la versión |
Así puedes saber la versión de un vistazo: xxxxxxxx-xxxx-4xxx-... es aleatorio y xxxxxxxx-xxxx-7xxx-... está ordenado por tiempo. Existen además dos valores especiales: el UUID nulo, todo ceros, y el UUID máximo, todo f, que añadió el RFC 9562. La norma pide generar en minúsculas y aceptar cualquier combinación al leer.
A efectos prácticos, sí. GUID es el nombre que usa Microsoft, y las herramientas de Windows suelen mostrarlo en mayúsculas y entre llaves: {7C4F1E2A-9B3D-4A6E-8F10-C2D5E7A9B341}. La única diferencia real aparece en binario: la estructura GUID de Windows guarda los tres primeros campos en orden little-endian. Si al mover los 16 bytes en bruto entre un sistema .NET o SQL Server y otro distinto los tres primeros grupos salen con los bytes invertidos, el motivo es ese.
| Versión | Se construye con | ¿Ordenable? | Observaciones |
|---|---|---|---|
| v1 | Marca de tiempo e identificador de nodo, normalmente la MAC | No como texto | Puede revelar qué equipo lo creó y cuándo |
| v3 / v5 | Espacio de nombres y nombre, con hash MD5 / SHA-1 | No | La misma entrada da siempre el mismo valor |
| v4 | 122 bits aleatorios | No | La más extendida con diferencia |
| v6 | Campos de v1 reordenados | Sí | Compatibilidad con sistemas v1 |
| v7 | Tiempo Unix en milisegundos y bits aleatorios | Sí | La opción recomendada si importa el orden temporal |
| v8 | Formato libre definido por el fabricante | Según el diseño | Para esquemas propios |
Hay también una versión 2, ligada a un antiguo estándar de seguridad para sistemas distribuidos, pero en el software actual prácticamente no aparece. El propio RFC 9562 aconseja usar v7 en lugar de v1 y v6 siempre que sea posible.
La versión original combina una marca de tiempo de 60 bits, que cuenta intervalos de 100 nanosegundos desde el 15 de octubre de 1582, una secuencia de reloj y el identificador de nodo del equipo que la genera. En la mayoría de implementaciones ese nodo es la dirección MAC de la tarjeta de red, de modo que el valor puede delatar qué ordenador lo creó y en qué momento. Como los campos de tiempo van con la parte baja primero, ordenarlos como texto tampoco produce un orden cronológico.
La gran mayoría de identificadores que verás son v4. De los 128 bits, 6 se reservan para versión y variante y los 122 restantes son aleatorios. No filtran información, pero tampoco tienen orden. El generador de este sitio produce esta versión con crypto.randomUUID() cuando el navegador lo ofrece y, si no, con la misma fuente aleatoria segura, crypto.getRandomValues. Los valores se crean en tu dispositivo y no se envían al servidor; la página solo suma un contador de uso anónimo.
La v7 coloca el tiempo Unix en milisegundos en los primeros 48 bits y rellena el resto con datos aleatorios. En 01a132dc-dfba-7aec-bf67-0d88cbe8fbc2, los doce primeros dígitos (01a132dcdfba) corresponden al 13 de octubre de 2026 a las 01:24:58,426 UTC. Un valor generado un milisegundo después queda por detrás al ordenar, tanto como texto como número. Esa propiedad resuelve casi por completo el problema de índices que verás más abajo. A cambio, cualquiera que tenga el valor puede saber cuándo se creó el registro; si eso importa, quédate con v4.
¿Pueden salir dos valores idénticos? Técnicamente sí. En la práctica, si se generan bien, no es algo para lo que tengas que prepararte. El cálculo es la paradoja del cumpleaños: en un grupo de 23 personas la probabilidad de que dos compartan cumpleaños ya supera el 50 %, porque crece con el número de parejas posibles y no con el de personas. Con los identificadores ocurre igual.
Las colisiones reales no salen de las matemáticas, sino de una mala aleatoriedad. Los culpables habituales son funciones caseras basadas en un generador no criptográfico, como Math.random() en JavaScript, máquinas virtuales clonadas de la misma instantánea que arrancan con el mismo estado aleatorio y procesos bifurcados que heredan una copia del estado del generador. Usar la función estándar de tu plataforma, respaldada por una fuente criptográfica, elimina esos riesgos.
Un identificador sirve para nombrar algo, no para protegerlo. Las consideraciones de seguridad del RFC 9562 dicen expresamente que no hay que suponer que estos valores son difíciles de adivinar ni usarlos como credenciales de acceso. Incluso un v4 generado con una fuente criptográfica acaba en URLs, registros y en el historial del navegador. Para enlaces de restablecimiento de contraseña o claves de API, genera un token largo, aleatorio y con caducidad pensado para eso.
La otra cara también importa: a diferencia de los enteros secuenciales, los v4 no se pueden recorrer probando /factura/1041, /factura/1042 y así sucesivamente. Eso oculta cuántos registros tienes y hace inviable adivinar al azar, pero no sustituye a la autorización. Si alguien llega a conocer el identificador del registro de otra persona, solo un control de acceso en el servidor lo detiene.
| Característica | INT / BIGINT | v4 | v7 |
|---|---|---|---|
| Tamaño | 4 / 8 bytes | 16 bytes | 16 bytes |
| Dónde se genera | En la base de datos, de forma centralizada | En cualquier sitio, sin coordinación | En cualquier sitio, sin coordinación |
| Orden de inserción | Creciente | Aleatorio | Creciente con el tiempo |
| Facilidad para adivinarlo | Trivial | Inviable | Tiempo visible, resto aleatorio |
| Fusionar conjuntos de datos | Conflictos probables | Sin problemas | Sin problemas |
La gran ventaja es conocer el identificador de un registro antes de que llegue a la base de datos. Una app móvil puede crear registros sin conexión, dos servidores en regiones distintas pueden escribir en la misma tabla y dos listas de clientes se pueden fusionar sin miedo a claves repetidas.
El precio es el tamaño y el comportamiento de los índices. Guardar el valor como texto en una columna CHAR(36) convierte 16 bytes en 36 caracteres e infla cada índice que lo incluya. Usa tipos nativos: en PostgreSQL, el tipo uuid ocupa 16 bytes; desde la versión 13 genera v4 con gen_random_uuid() y desde la 18, v7 con uuidv7(). En MySQL 8, usa una columna BINARY(16) con UUID_TO_BIN() y BIN_TO_UUID(); como el UUID() de MySQL devuelve v1, el segundo argumento de UUID_TO_BIN(UUID(), 1) reordena los campos de tiempo para que el valor guardado sea amigable con el índice.
El otro coste es el azar. En motores que agrupan la tabla por clave primaria, como InnoDB, cada fila nueva con v4 se escribe en un punto aleatorio del índice: más divisiones de página y peor aprovechamiento de la caché. Como la v7 crece con el tiempo, las filas nuevas caen al final del índice y ese coste casi desaparece.
Si la forma con guiones te parece larga para una URL, codifica los 16 bytes con base64url. 7c4f1e2a-9b3d-4a6e-8f10-c2d5e7a9b341 se convierte en fE8eKps9Sm6PEMLV56mzQQ: 22 caracteres en vez de 36. No se pierde nada, pero el formato no es estándar, así que ambos extremos necesitan código de conversión y en la base de datos conviene seguir guardando el valor binario de 16 bytes.
El RFC 9562 pide generarlos en minúsculas y tratar ambas formas como iguales al leer. El problema aparece en el código que los compara como texto: A1B2... y a1b2... son el mismo identificador, pero no coinciden. Normalizar antes de guardar evita el fallo.
Con valores v4 bien generados la probabilidad es prácticamente nula; incluso con mil millones queda por debajo de 10⁻¹⁹. Los duplicados reales casi siempre vienen de un generador aleatorio defectuoso o de un código que asigna por error el mismo valor a dos registros.
Como identificador, sí; revela menos que un número secuencial. Pero no sustituye a la comprobación de permisos. Si conocer el enlace no debe bastar para ver el registro, aplica la autorización en el servidor.
La herramienta de este sitio genera entre 1 y 100 valores v4 por ejecución, con 5 por defecto. Si necesitas más, vuelve a ejecutarla o usa la función estándar de tu lenguaje en tu propio código.
Para secretos en lugar de identificadores, contraseñas seguras e identificadores continúa donde termina este artículo. La codificación de la forma de 22 caracteres se explica en qué es Base64, y si mueves registros con identificadores entre hojas de cálculo y APIs, CSV y JSON: diferencias repasa las trampas de la conversión.
