Un identificador único sin preguntar a nadie
Imagina que dos servidores en continentes distintos, una app móvil sin cobertura y un script nocturno tienen que crear registros a la vez, cada uno con su identificador, y que ninguno puede consultar a los demás. Ese es el problema que resuelve el UUID (Universally Unique Identifier): un número de 128 bits que cualquiera puede generar por su cuenta con la garantía práctica de que jamás chocará con el de otro. Se escribe como 32 dígitos hexadecimales en cinco grupos, algo como «f47ac10b-58cc-4372-a567-0e02b2c3d479».
Esta herramienta genera de uno a cien UUID de una vez, con opciones para quitar los guiones o pasarlos a mayúsculas, y un botón para copiarlos todos juntos: perfecto para rellenar datos de prueba o preparar inserciones en bloque.
Por qué la versión 4 domina
El estándar define varias versiones de UUID: las históricas v1 y v2 mezclaban la hora con la dirección MAC del equipo (y filtraban así información del hardware), la v3 y la v5 derivan el identificador de un nombre mediante un hash, y la v4 es puro azar: 122 de sus 128 bits se rellenan con aleatoriedad criptográfica y los 6 restantes marcan la versión y la variante. Al no depender del reloj ni de la máquina, la v4 no revela nada sobre quién la generó ni cuándo, y por eso es la opción por defecto en casi cualquier proyecto moderno.
¿De verdad no se repiten nunca?
Matemáticamente pueden repetirse; en la práctica, olvídate. Con 122 bits aleatorios hay unas 5,3 × 10³⁶ combinaciones. Aplicando la paradoja del cumpleaños, necesitarías generar un millón de UUID por segundo durante más de 85 000 años para que la probabilidad de una sola colisión llegara al 50 %. Por eso ningún sistema serio comprueba si un UUID v4 «ya existe»: se asume la unicidad y punto. Aquí se generan con crypto.randomUUID(), que usa el generador criptográfico del navegador, no un aleatorio predecible.
UUID o autoincremental: cuándo usar cada uno
La alternativa clásica es el entero autoincremental (1, 2, 3…) que asigna la base de datos. Elige UUID cuando:
- Varios sistemas insertan datos sin coordinarse: microservicios, réplicas, bases de datos distribuidas o apps que funcionan sin conexión y sincronizan después.
- Necesitas el identificador antes de escribir en la base de datos, por ejemplo para enlazar objetos creados en el cliente.
- No quieres exponer información: un ID secuencial en la URL revela cuántos pedidos o usuarios tienes y permite adivinar los vecinos.
El autoincremental sigue ganando cuando una única base de datos centraliza las escrituras y te importa el rendimiento puro: ocupa menos (4 u 8 bytes frente a 16), mantiene los índices ordenados y es más cómodo de leer en un log o dictar por teléfono. De hecho, muchos equipos combinan ambos: clave interna autoincremental e identificador público en formato UUID.
Detalles prácticos que conviene saber
- Las mayúsculas no cambian el valor: el estándar los escribe en minúsculas, pero muchos sistemas los muestran en mayúsculas. Son el mismo identificador.
- Los guiones son presentación. Algunos sistemas los omiten para ahorrar espacio; por eso puedes generarlos aquí sin ellos.
- Un UUID v4 no sirve como secreto de autenticación por sí solo: es único, pero para credenciales usa el generador de contraseñas.
Si trabajas con identificadores y datos, también te pueden servir el generador de hash, el generador de slugs y el resto de herramientas.