
UUID, ULID y Nanoid: ¿qué identificador único elegir en 2026?
UUID v4 aleatorio, UUID v7 y ULID ordenables, Nanoid compacto: comparativa y generadores en línea para claves primarias e IDs públicos.
Identificadores aleatorios, ordenables o compactos para necesidades distintas
Un simple auto-incremento revela cuántas filas tiene una tabla. Se coordina mal entre varios servidores que escriben a la vez, y se adivina con facilidad: el ID 1042 deja suponer que existe un ID 1041. Por eso las aplicaciones generan los ID en el cliente o en el servidor, sin contador central. Pero «único e impredecible» no significa lo mismo en todos los formatos. El generador de UUID produce un UUID v4 aleatorio, un UUID v7 que empieza por una marca de tiempo, o el UUID nil para pruebas. El generador de ULID persigue el mismo objetivo que UUID v7, un identificador ordenable por fecha de creación, con una cadena Base32 más corta. El generador de Nanoid prescinde de la marca de tiempo y dedica cada carácter al azar, así que la cadena es más corta con la misma entropía. Los tres funcionan en el navegador y están agrupados en el hub de utilidades para desarrolladores, junto al probador de regex y al generador de contraseñas.
Elegir la herramienta adecuada según el contexto
Prototipado, pruebas y comprobaciones visuales antes de escribir una sola línea de código de servidor.
El generador en línea prototipa el formato; no sustituye la generación a escala de producción.
uuid, ulid, nanoid en Node) evita pasar por el navegadorErrores que salen caros una vez en producción
Una clave primaria con valores UUID v4 inserta cada fila nueva en una posición aleatoria del índice B-tree. En una tabla con mucha actividad, eso fragmenta las páginas y ralentiza la inserción. La causa es el azar puro, no el UUID en sí. UUID v7 (RFC 9562) coloca una marca de tiempo en milisegundos en sus primeros 48 bits y rellena el resto con bits aleatorios. ULID aplica la misma idea en Base32. Los valores nuevos llegan entonces al final del índice, como con un auto-incremento, sin exponer un contador aprovechable. Según la RFC 9562, la diferencia puede llegar a un orden de magnitud o más. El generador de UUID pasa de v4 a v7 sin cambiar la forma del campo (36 caracteres con guiones). El generador de ULID ofrece la variante más corta, de 26 caracteres.
Sustituir un auto-incremento por un UUID, un ULID o un Nanoid impide la enumeración simple (probar ?id=124, luego 125…). Pero no comprueba ninguna autorización. Un identificador obtenido por otra vía (enlace compartido, línea de registro, cabecera Referer) sigue siendo legible si la API no comprueba de quién es el recurso. ULID añade un problema propio. Sus 10 primeros caracteres dejan ver la fecha de creación en claro. Para una clave primaria no importa. Para un token que debe seguir siendo opaco, sí importa. Quien conozca más o menos la fecha de creación reduce el espacio de búsqueda antes de atacar la parte aleatoria.
La resistencia a colisiones de un Nanoid depende a la vez del tamaño y del alfabeto. El ajuste por defecto de la herramienta, 21 caracteres del alfabeto URL-safe de 64 símbolos, lleva 126 bits aleatorios, frente a 122 en un UUID v4. Cualquier otro ajuste cambia ese cálculo. Con 8 caracteres del mismo alfabeto, la probabilidad de al menos una colisión llega al 1 % hacia los 2,4 millones de identificadores. El alfabeto Numérico (10 símbolos) también reduce el espacio: 21 cifras dan unos 70 bits. Nada te avisa, salvo la entropía en bits que muestra el botón de información junto al campo Tamaño.
El selector de formato de la herramienta UUID (simple, llaves, URN) y el interruptor de mayúsculas cambian la escritura, no los 128 bits subyacentes. Una columna que compara cadenas tal cual no sabe que {550e8400-…} y urn:uuid:550e8400-… nombran el mismo UUID si no se normalizan antes. ULID tiene la misma trampa. Crockford Base32 no distingue mayúsculas al decodificar, pero una restricción UNIQUE sobre una columna de texto suele distinguirlas, como PostgreSQL por defecto.
Formato, tamaño y orden de las cuatro variantes
Un mismo objetivo, la unicidad sin coordinador central, en cuatro formas distintas.
Las opciones reales de cada herramienta, tal como existen hoy.
Tres situaciones concretas donde la elección del formato tiene un efecto medible.
Generar, ajustar, copiar
En el generador de UUID, la lista se vuelve a generar en cuanto cambias una opción: no hay botón Generar. En el generador de ULID, la marca de tiempo decodificada de cada ID aparece justo debajo de su fila.
1. Elegir la versión o la opción Monótono
En UUID, v4 da azar puro, v7 un orden por tiempo y nil el UUID de ceros, siempre con una sola unidad. Los v7 de una misma lista suelen compartir milisegundo, así que no quedan ordenados entre sí. En ULID, todos los ID de una lista comparten el mismo milisegundo y salen en orden aleatorio. Activa Monótono para obtenerlos en orden estrictamente ascendente.
2. Ajustar guiones, mayúsculas y formato
En UUID, el formato URN impone guiones y minúsculas y desactiva los dos interruptores. En ULID, las mayúsculas están activas por defecto; Crockford Base32 se decodifica igual en minúsculas.
3. Ajustar la cantidad (1 a 50) y copiar
Copia toda la lista de una vez, descárgala en .txt o copia fila a fila con el botón de cada ID.
El generador de Nanoid muestra la entropía en bits en la ayuda emergente del botón de información junto a Tamaño. El valor sigue cada cambio de tamaño o de alfabeto, así que no tienes que calcularlo de cabeza.
Los mismos formatos en el servidor, en Node
Node ofrece crypto.randomUUID() para un UUID v4, sin dependencias. Desde Node 24.16 y 26.1, crypto.randomUUIDv7() genera también un v7. En versiones anteriores, el pequeño paquete uuid se encarga de la variante ordenable, como en el ejemplo.
Ejemplo básico
Node no tiene soporte nativo para ULID. El paquete ulid genera ULID y decodifica su marca de tiempo incorporada.
Ejemplo básico
El paquete nanoid usa el mismo alfabeto URL-safe y el mismo tamaño por defecto que la herramienta (21 caracteres). Su función customAlphabet admite un alfabeto y un tamaño a medida.
Ejemplo básico
Sin instalación, sin envío de datos, hasta 50 ID por lista y todas las opciones de formato de las tres herramientas. A cambio, no hay generación a gran volumen en el navegador ni orden monótono entre listas, pestañas o procesos, y un alfabeto Nanoid personalizado se limita a 256 caracteres. Usa las páginas para prototipar un esquema o producir datos de prueba, y mantén uuid, ulid y nanoid en el servidor para producción.
Conclusión
Ningún identificador sirve para todos los casos. UUID v4 sigue siendo la opción correcta para un identificador puramente opaco, sin necesidad de orden y con el soporte nativo más amplio. UUID v7 o ULID toman el relevo cuando el orden de inserción importa para el rendimiento del índice o para ordenar sin una columna created_at propia. Nanoid da la cadena más corta para una entropía dada, algo útil en una URL. Ninguno de los tres sustituye un control de autorización en el servidor. Tampoco están pensados para generar a gran volumen en el navegador: para eso están las bibliotecas de servidor uuid, ulid y nanoid. Si estos identificadores viajan en la carga JSON de una API, la guía sobre optimizar una API REST JSON completa esta lectura. El validador de JSON Schema comprueba después la forma esperada de un campo id.
Generar un identificador en el navegador
uuid, ulid, nanoid), no el generador del navegadorArtículos relacionados

Pega un token y un JWKS para comprobar una firma RS256, ES256 o HS256 en el navegador. Elección de la clave por kid, errores medidos y claims que revisar.

HTTP/2 y HTTP/3 cambian el trayecto de los archivos, no su peso. Mediciones de tamaño, compilación y bundling muestran lo que la minificación aún aporta.

Convierte un epoch Unix en una fecha legible y al revés, distingue segundos de milisegundos y evita las trampas de zona horaria, JWT y cambio de hora.