UUID, ULID y Nanoid: ¿qué identificador único elegir en 2026?

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.

23.09.2026
13 min de lectura
Compartir este artículo:
uuidulidnanoididentifiersdatabasetools-dev

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.

UUID: v4, v7 o nil, con o sin guiones, en minúsculas o mayúsculas, formato simple, llaves o URN, de 1 a 50 ID por lista
ULID: 26 caracteres en Crockford Base32, mayúsculas por defecto, opción Monótono que mantiene una lista en orden ascendente y marca de tiempo decodificada bajo cada ID
Nanoid: cualquier tamaño de 2 a 64 (21 por defecto, cinco tamaños predefinidos), alfabeto URL-safe, alfanumérico, numérico, sin homoglifos o personalizado, entropía mostrada en bits
Los tres generan sus identificadores con la API Web Crypto del navegador, sin enviar datos; sin crypto.getRandomValues, ULID y Nanoid muestran un error en lugar de un identificador más débil
Sin botón Generar: la lista se vuelve a generar cada vez que cambias una opción, con Copiar todo, descarga en .txt y un botón de copia en cada fila

Elegir la herramienta adecuada según el contexto

Buenos usos del generador en línea

Prototipado, pruebas y comprobaciones visuales antes de escribir una sola línea de código de servidor.

Prototipar un esquema de base de datos y comparar enseguida las claves v7 con las claves v4
Producir datos de prueba, de 10 a 50 ID de una vez, copiados o descargados en .txt
Comprobar que la opción Monótono del generador de ULID mantiene una lista en orden ascendente antes de confiar en el mismo comportamiento en el servidor
Recalcular la entropía real de un Nanoid personalizado (alfabeto, tamaño) antes de fijarla en una especificación de API
Ilustrar una discusión de equipo sobre ordenable frente a aleatorio sin escribir una línea de código
Lo que debe quedarse en el servidor o en una biblioteca

El generador en línea prototipa el formato; no sustituye la generación a escala de producción.

Generación de ID a gran volumen en producción: una biblioteca de servidor (uuid, ulid, nanoid en Node) evita pasar por el navegador
Tokens de seguridad (restablecimiento de contraseña, sesión, invitación): un secreto dedicado, nunca un identificador público reutilizado
Control de autorización sobre un recurso: un identificador impredecible nunca sustituye una comprobación de propiedad en el servidor
Migrar un auto-incremento existente a UUID o ULID en producción: planifica la escritura doble y el nuevo índice antes de retirar el contador antiguo

Errores que salen caros una vez en producción

Usar un UUID v4 aleatorio como clave primaria indexada

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.

Elegir v4 por defecto para una clave primaria con muchas escrituras y descubrir después la fragmentación del índice en producción
Suponer que un UUID «aleatorio» es más seguro que uno «ordenable», cuando un v7 conserva 74 bits aleatorios y un ULID 80
Mezclar v4 y v7 en la misma columna esperando que se comparen cronológicamente entre sí
No comprobar nunca si la base de datos o el ORM ya recomiendan un identificador ordenable para claves indexadas
Reserva v4 para un identificador puramente opaco (sesión, token, valor de un solo uso). Cambia a v7 o ULID en cuanto la tabla reciba escrituras continuas y el orden de inserción importe para el rendimiento del índice.
Creer que un identificador impredecible sustituye un control de autorización

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.

Quitar una comprobación de propiedad en el servidor porque el identificador es «difícil de adivinar»
Usar un ULID como token de restablecimiento de contraseña o de invitación, asumiendo que es tan opaco como un secreto dedicado
Publicar ULID en URL públicas sin darse cuenta de que revelan la fecha de creación del recurso
Contar con un orden monótono entre varias listas o procesos, cuando la opción Monótono solo cubre los ID de una misma lista
UUID, ULID y Nanoid sustituyen un contador, no una sesión ni un secreto. Para un token de vida corta, genera un valor dedicado y comprueba siempre la autorización en el servidor.
Reducir el alfabeto o el tamaño de un Nanoid sin recalcular la entropía

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.

Cambiar al alfabeto Numérico para un identificador que debe seguir siendo único a gran escala, sin revisar la entropía mostrada
Bajar a 6 u 8 caracteres para un slug «más corto» sin estimar cuántos identificadores se crearán de verdad
Pegar un alfabeto personalizado con caracteres repetidos y contar con su longitud, cuando la herramienta quita los duplicados antes de calcular la entropía
Confundir el alfabeto «Sin homoglifos» (pensado para un código leído en voz alta) con un alfabeto pensado para la densidad de información
Un Nanoid acortado sin recalcular la entropía puede parecer correcto en pruebas y aun así colisionar una vez alcanzado el volumen real de producción.
Mezclar variantes de formato dentro del mismo conjunto de datos

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.

Generar UUID en formato urn:uuid: para una exportación y luego compararlos tal cual con UUID planos ya almacenados en la base de datos
Activar las llaves para una prueba manual y olvidar quitarlas antes de importar
Guardar los ULID en mayúsculas cuando vienen del cliente y en minúsculas cuando el servidor los recalcula
No normalizar mayúsculas y guiones antes de una comparación de igualdad o una restricción UNIQUE
Elige un único formato de almacenamiento (normalmente en minúsculas, con guiones, sin prefijo) y normaliza cualquier valor externo antes de compararlo.

Formato, tamaño y orden de las cuatro variantes

UUID v4, UUID v7, ULID, Nanoid

Un mismo objetivo, la unicidad sin coordinador central, en cuatro formas distintas.

UUID v4 (RFC 9562): 128 bits, 122 de ellos aleatorios, 36 caracteres con guiones, como 550e8400-e29b-41d4-a716-446655440000, donde el 4 que abre el tercer grupo indica la versión. No se ordena por fecha de creación. Es el formato más extendido, con un tipo propio en PostgreSQL y MariaDB.
UUID v7: la misma forma de 36 caracteres, pero los primeros 48 bits llevan una marca de tiempo en milisegundos y el dígito de versión es 7. Se ordena por tiempo incluso como texto y sigue siendo un UUID estándar, con 74 bits aleatorios.
ULID: 26 caracteres en Crockford Base32 (por ejemplo 01HXYZ0123456789ABCDEFGHJK), 48 bits de tiempo y luego 80 bits aleatorios. Mismo comportamiento de orden que UUID v7, cadena más corta, insensible a mayúsculas al decodificar.
Nanoid: longitud de 2 a 64 caracteres (21 por defecto) y alfabeto a elegir. Sin marca de tiempo incorporada, un Nanoid no se ordena por fecha de creación. Es el más compacto de los cuatro con una entropía comparable.
Lo que ofrecen realmente los generadores de FastMinify

Las opciones reales de cada herramienta, tal como existen hoy.

uuid-generator: versión v4, v7 o nil, guiones y mayúsculas activables, formato simple, llaves o URN, de 1 a 50 ID por lista. URN impone guiones y minúsculas, y nil da siempre un solo ID. Cada fila v7 muestra su marca de tiempo.
ulid-generator: mayúsculas por defecto, opción Monótono, marca de tiempo decodificada bajo cada ID, de 1 a 50 por lista. Todos los ID de una lista comparten el mismo milisegundo. Monótono suma uno a la parte aleatoria anterior en lugar de sacar una nueva.
nanoid-generator: tamaño de 2 a 64 (tamaños predefinidos 8, 12, 16, 21 y 32), entropía en bits, de 1 a 50 por lista. El alfabeto es URL-safe por defecto, o bien alfanumérico, numérico, sin homoglifos o personalizado. Un alfabeto personalizado admite hasta 256 caracteres y se le quitan los duplicados.
Los tres funcionan en el navegador con Web Crypto y no envían nada. ULID y Nanoid no tienen alternativa más débil: sin crypto.getRandomValues, muestran un error en lugar de una lista. El generador de UUID, en cambio, recurre entonces a Math.random.
Cuándo el orden marca realmente la diferencia

Tres situaciones concretas donde la elección del formato tiene un efecto medible.

Tabla con muchas escrituras y clave primaria indexada: v4 dispersa las inserciones por todo el índice. v7 o ULID se añaden al final, como un auto-incremento, sin exponer un contador.
Orden «más recientes primero» sin una columna created_at dedicada: posible directamente sobre el ID con v7 y ULID (orden lexicográfico = orden cronológico), imposible con v4 o Nanoid.
Sincronización entre sistemas distribuidos sin coordinador central: los cuatro formatos mantienen identificadores únicos en la práctica sin servidor central, algo que un auto-incremento no puede hacer.
URL pública más corta con un presupuesto de entropía comparable: un Nanoid de 21 caracteres (por defecto) supera los 36 caracteres de un UUID y los 26 de un ULID.

Generar, ajustar, copiar

Configurar los generadores de UUID y ULID

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

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

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

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.

Ajustar el tamaño y el alfabeto del Nanoid antes de copiar

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.

Tamaño: de 2 a 64 caracteres, con el control deslizante, el campo numérico o los tamaños predefinidos 8 / 12 / 16 / 21 / 32
Alfabeto: URL-safe por defecto, sin + / = que codificar en una URL, o bien alfanumérico, numérico, sin homoglifos (excluye 0, O, o, I, l y 1) o personalizado de hasta 256 caracteres
Un alfabeto personalizado pierde sus caracteres repetidos y necesita al menos 2 distintos
De 1 a 50 ID por lista, Copiar todo, descarga en .txt o botón de copia en cada fila
Sin alternativa si el navegador no ofrece crypto.getRandomValues: un mensaje de error sustituye la lista en lugar de un identificador más débil

Los mismos formatos en el servidor, en Node

UUID v4 y v7 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

const crypto = require('node:crypto') // v4 — integrado en Node, sin dependencias const id = crypto.randomUUID() // v7 — crypto.randomUUID() de Node solo genera v4 const { v7: uuidv7 } = require('uuid') const sortableId = uuidv7()
ULID en Node

Node no tiene soporte nativo para ULID. El paquete ulid genera ULID y decodifica su marca de tiempo incorporada.

Ejemplo básico

const { ulid, decodeTime } = require('ulid') const id = ulid() // 26 caracteres, mayúsculas const createdAtMs = decodeTime(id)
Nanoid en Node

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

const { nanoid, customAlphabet } = require('nanoid') const id = nanoid() // 21 caracteres, alfabeto url por defecto const numericId = customAlphabet('0123456789', 12)()
FastMinify uuid-generator / ulid-generator / nanoid-generator

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.

UUID v4 para un identificador puramente opaco, sin necesidad de orden
UUID v7 o ULID en cuanto el orden de inserción importe para el índice o para un orden a nivel de aplicación
Nanoid para la cadena más corta posible con un presupuesto de entropía dado, especialmente en una URL
Ninguno de los tres sustituye un control de autorización en el servidor
Generación a gran volumen en producción: una biblioteca de servidor (uuid, ulid, nanoid), no el generador del navegador
Compartir este artículo
Compartir este artículo: