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:

uuid

ulid

nanoid

identifiers

database

tools-dev

Aleatorio, ordenable o compacto: tres necesidades distintas para una cadena

Un simple auto-incremento revela cuántas filas tiene una tabla, se coordina mal entre varios servidores que escriben a la vez, y es adivinable — el ID 1042 sugiere que existe un ID 1041. Por eso las aplicaciones generan IDs en el cliente o en el servidor sin un contador central. Pero «único e impredecible» no significa lo mismo según el formato elegido. El generador de UUID produce un UUID v4 puramente aleatorio, un UUID v7 cuyos primeros bits codifican una marca de tiempo (por eso se puede ordenar), o el UUID nil de prueba. El generador de ULID persigue el mismo objetivo que UUID v7 — un identificador ordenable por fecha de creación — con una escritura más corta en Base32. El generador de Nanoid abandona la marca de tiempo incorporada para optimizar la longitud de la cadena con un presupuesto de entropía dado. Los tres funcionan completamente 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: versiones v4 (aleatorio), v7 (ordenable, marca de tiempo de 48 bits) o nil; guiones, mayúsculas y formato (plano, llaves, urn:uuid:) ajustables; de 1 a 50 IDs por lote

ULID: 26 caracteres en Crockford Base32, mayúsculas por defecto, modo monótono para un orden garantizado dentro del mismo lote, marca de tiempo decodificada bajo cada ID generado

Nanoid: tamaño ajustable de 2 a 64 caracteres (por defecto 21, preajustes 8/12/16/21/32), alfabeto url / alfanumérico / numérico / sin caracteres ambiguos / personalizado hasta 256 caracteres, entropía mostrada en directo

Los tres generan mediante 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 actualiza al instante con cada cambio de opción, con copiar todo, descarga .txt o copia línea a línea

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 de inmediato claves v7 frente a claves v4

Producir datos de prueba o fixtures — de 10 a 50 IDs de una vez, copiados o descargados en .txt

Comprobar visualmente que el modo monótono del generador de ULID mantiene un orden ascendente dentro de un mismo lote antes de confiar en él 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 IDs de alto rendimiento en producción — una biblioteca de servidor (uuid, ulid, nanoid en Node) evita cualquier ida y vuelta al 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 — planifique 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 alimentada con valores UUID v4 inserta cada nueva fila en una posición aleatoria del índice B-tree, lo que fragmenta las páginas y ralentiza las escrituras en una tabla de alto volumen. No es un problema de UUID en general, sino de aleatoriedad pura: UUID v7 (RFC 9562) codifica una marca de tiempo en milisegundos en sus primeros 48 bits y completa el resto de forma aleatoria, y ULID hace lo mismo en Base32. Ambos se añaden al final del índice, como un auto-incremento, sin exponer un contador utilizable. El generador de UUID cambia de v4 a v7 sin modificar la forma del campo (36 caracteres con guiones); el generador de ULID ofrece la alternativa 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 necesariamente más seguro que uno «ordenable» — la parte aleatoria de un v7 o de un ULID sigue siendo amplia (74 a 80 bits), solo cambia el orden de inserción

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

Reserve v4 para un identificador puramente opaco (sesión, nonce, token). Cambie a v7 o ULID en cuanto la tabla se escriba de forma continua 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 trivial (probar ?id=124, luego 125…) pero no verifica la autorización de nadie: un identificador obtenido por otro canal (enlace compartido, línea de log, cabecera referrer) sigue siendo legible si la API no comprueba la propiedad del recurso. ULID añade un problema propio: sus primeros 10 caracteres codifican la marca de tiempo de creación en claro. Esto es inofensivo para una clave primaria, pero no para un token que debería seguir siendo opaco — quien conozca aproximadamente la fecha de creación reduce el espacio de búsqueda antes incluso 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 URLs públicas sin darse cuenta de que revelan la fecha de creación del recurso

No probar nunca el modo monótono del generador de ULID antes de confiar en él en el servidor para garantizar un orden dentro del mismo milisegundo

UUID, ULID y Nanoid sustituyen un contador, no una sesión ni un secreto. Para un token de vida corta, genere un valor dedicado y compruebe 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 por completo del producto tamaño × alfabeto. El ajuste por defecto de la herramienta (21 caracteres sobre el alfabeto url de 64 símbolos) apunta a una probabilidad de colisión comparable a la de un UUID v4 a un ritmo de generación realista — pero cada preajuste cambia ese cálculo. Cambiar al alfabeto «numeric» (10 símbolos) o bajar a 6-8 caracteres para un slug más corto puede reducir el espacio de identificadores en varios órdenes de magnitud, sin que nada lo indique salvo el contador de entropía mostrado en directo junto al campo de 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-8 caracteres para un slug «más corto» sin estimar el ritmo real de generación

Pegar un alfabeto personalizado con caracteres repetidos esperando obtener la longitud mostrada — los duplicados se eliminan automáticamente

Confundir el alfabeto «sin caracteres ambiguos» (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 (plano, llaves, urn:uuid:) y el interruptor de mayúsculas cambian la representación textual, no los 128 bits subyacentes — pero una columna que compara cadenas planas no sabe que {550e8400-…} y urn:uuid:550e8400-… nombran el mismo UUID sin normalizar antes. La misma lógica se aplica a ULID: Crockford Base32 se define como insensible a mayúsculas al decodificar, pero una restricción UNIQUE sobre una cadena sí es sensible a mayúsculas.

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

Almacenar ULID unas veces en mayúsculas (generados en el cliente) y otras en minúsculas (recalculados en el servidor)

No normalizar mayúsculas y guiones antes de una comparación de igualdad o una restricción UNIQUE

Elija un único formato de almacenamiento (típicamente en minúsculas, con guiones, sin prefijo) y normalice cualquier valor externo antes de compararlo.

Formato, tamaño, orden: lo que realmente distingue a las cuatro variantes

UUID v4, UUID v7, ULID, Nanoid

Mismo objetivo — unicidad sin coordinador central — cuatro formas distintas.

UUID v4: 128 bits, 122 de ellos aleatorios, 36 caracteres con guiones (por ejemplo 550e8400-e29b-41d4-a716-446655440000). No ordenable por fecha de creación. El formato más extendido, soportado de forma nativa por casi todas las bases de datos (RFC 9562).

UUID v7: misma forma de 36 caracteres, pero los primeros 48 bits codifican una marca de tiempo en milisegundos — ordenable de forma lexicográfica y cronológica a la vez, sin dejar de ser un UUID estándar.

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 ajustable de 2 a 64 caracteres (por defecto 21), alfabeto ajustable. Sin marca de tiempo incorporada — un Nanoid no se ordena por fecha de creación. El más compacto de los cuatro con un presupuesto de entropía comparable.

Lo que ofrecen realmente los generadores de FastMinify

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

uuid-generator: versiones v4 / v7 / nil, guiones activados/desactivados, mayúsculas activadas/desactivadas, formato plano / llaves / urn:uuid: (urn fuerza guiones activados y mayúsculas desactivadas), de 1 a 50 IDs por lote (forzado a 1 con nil).

ulid-generator: mayúsculas por defecto, modo monótono (incrementa la parte aleatoria en lugar de generar una nueva dentro del mismo lote), marca de tiempo decodificada mostrada bajo cada ID generado, de 1 a 50 por lote.

nanoid-generator: tamaño 2-64 con preajustes 8/12/16/21/32, alfabeto url (por defecto) / alfanumérico / numérico / sin caracteres ambiguos / personalizado (hasta 256 caracteres, deduplicado automáticamente), entropía mostrada en directo, de 1 a 50 por lote.

Los tres funcionan enteramente en el navegador mediante Web Crypto, sin enviar datos; ULID y Nanoid no tienen alternativa insegura — sin crypto.getRandomValues, la herramienta muestra un error en lugar de un identificador más débil.

Cuándo la ordenabilidad marca realmente la diferencia

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

Tabla de alto volumen de escrituras con clave primaria indexada: v4 fragmenta el índice por inserciones aleatorias; v7 o ULID se añaden al final del índice, 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 garantizan la unicidad sin un servidor central — precisamente lo 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

UUID y ULID: elegir la versión y luego ajustar el formato

En el generador de UUID, la lista se actualiza en cuanto cambia una opción — no hay un botón «generar» separado. En el generador de ULID, la marca de tiempo decodificada de cada ID aparece justo debajo de la fila generada.

Paso 1 — Elegir la versión o la opción de orden

UUID: v4 para aleatoriedad pura, v7 para ordenabilidad, nil para el UUID de ceros de prueba (el número se fuerza entonces a 1). ULID: active el modo monótono si genera varios IDs dentro del mismo milisegundo y necesita un orden garantizado.

Paso 2 — Ajustar guiones, mayúsculas y formato

En UUID, elegir el formato urn:uuid: fuerza automáticamente los guiones y desactiva el interruptor de mayúsculas. En ULID, las mayúsculas están activas por defecto; la decodificación Crockford Base32 sigue siendo correcta incluso en minúsculas.

Paso 3 — Ajustar la cantidad (1 a 50) y copiar

Copie toda la lista de una vez, descárguela en .txt, o copie fila a fila con el botón de cada ID.

Nanoid: ajustar tamaño y alfabeto antes de copiar

El generador de Nanoid muestra la entropía en bits en directo en cuanto cambia el tamaño o el alfabeto, para no tener que calcularla de cabeza.

Tamaño: de 2 a 64 caracteres, preajustes rápidos 8 / 12 / 16 / 21 / 32

Alfabeto: url (por defecto, sin + / = para poder usarse tal cual en una URL), alfanumérico, numérico, sin caracteres ambiguos (excluye 0/O y 1/l/I), o personalizado hasta 256 caracteres

Un alfabeto personalizado se deduplica automáticamente y necesita al menos 2 caracteres distintos para generar

De 1 a 50 IDs por lote, copiar todo, descarga .txt, o copia fila a fila

Sin alternativa si el navegador no ofrece crypto.getRandomValues — un mensaje de error sustituye la lista en lugar de producir un identificador más débil

Los mismos formatos en el servidor, en Node

UUID v4 y v7 en Node

Node expone crypto.randomUUID() de forma nativa para un UUID v4, sin ninguna dependencia. El módulo crypto integrado de Node no genera v7 — un pequeño paquete npm como uuid se encarga de la variante ordenable.

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 ofrece la generación y la decodificación de la 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 reproduce el alfabeto url y el tamaño por defecto de la herramienta (21 caracteres), con customAlphabet para un alfabeto o 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 IDs por lote, opciones de formato completas para los tres formatos. Contrapartida: sin generación de alto rendimiento en el navegador, sin garantía de monotonía entre pestañas o procesos, y un alfabeto Nanoid personalizado limitado a 256 caracteres. Use las páginas para prototipar un esquema o producir fixtures; mantenga uuid, ulid y nanoid en el servidor para producción.

Conclusión

No existe un identificador «mejor» en términos absolutos. UUID v4 sigue siendo la opción correcta para un identificador puramente opaco, sin necesidad de orden, con el soporte nativo más amplio. UUID v7 o ULID toman el relevo en cuanto el orden de inserción importa para el rendimiento de un índice o para un orden a nivel de aplicación sin una columna created_at dedicada. Nanoid busca 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, y ninguno está pensado para una generación de alto rendimiento en el navegador — para eso están las bibliotecas de servidor uuid, ulid y nanoid. Si estos identificadores viajan dentro de la carga JSON de una API, la guía sobre optimizar una API REST JSON complementa esta lectura, igual que el validador de JSON Schema para comprobar la forma esperada de un campo id.

Generar un identificador en el navegador

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 de alto rendimiento en producción: una biblioteca de servidor (uuid, ulid, nanoid), no el generador del navegador

Compartir este artículo

Compartir este artículo:

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

Aleatorio, ordenable o compacto: tres necesidades distintas para una cadena

Elegir la herramienta adecuada según el contexto

Errores que salen caros una vez en producción

Formato, tamaño, orden: lo que realmente distingue a las cuatro variantes

Generar, ajustar, copiar

Paso 1 — Elegir la versión o la opción de orden

Paso 2 — Ajustar guiones, mayúsculas y formato

Paso 3 — Ajustar la cantidad (1 a 50) y copiar

Los mismos formatos en el servidor, en Node

Ejemplo básico

Ejemplo básico

Ejemplo básico

Conclusión

Artículos relacionados