Fija aquí tus herramientas. Se guardan en este navegador.
Fija una herramienta y su pegatina aparece aquí.
Genera en lote UUID v4, UUID v7 ordenados por tiempo, ULID y Nano ID, y consulta la versión y el timestamp que contiene un ID.
Un UUID versión 4 son 122 bits aleatorios. No dice nada de cuándo ni dónde se generó, y es la opción habitual cuando un ID solo tiene que ser único. El UUID versión 7, estandarizado en la RFC 9562 en 2024, pone un timestamp Unix de 48 bits en milisegundos delante de 74 bits aleatorios. Los ID nuevos se ordenan después de los antiguos, así que las filas insertadas juntas quedan juntas en el índice de la base de datos, a cambio de mostrar el momento de creación a cualquiera que vea el ID.
Un ULID sigue la misma idea con otra forma de escribirlo: 48 bits de tiempo y 80 bits aleatorios en 26 caracteres de Crockford Base32, sin guiones y sin distinguir mayúsculas de minúsculas. Un Nano ID es una cadena aleatoria cuya longitud y alfabeto eliges tú. El valor por defecto, 21 caracteres de 64 símbolos seguros para URL, contiene 126 bits, algo más que un UUID versión 4, en una cadena más corta.
En teoría, los ID aleatorios pueden coincidir. Con la versión 4 habría que generar unos 2,7 trillones (2,7 × 10^18) de UUID antes de que la probabilidad de una sola repetición llegue a la mitad, y por eso las aplicaciones los tratan como únicos. Un Nano ID más corto o un alfabeto pequeño reducen ese margen: la línea bajo las opciones muestra cuántos bits aleatorios da tu elección.
Un ID es un identificador, no un secreto. Las versiones 1, 6 y 7 y los ULID revelan cuándo se generaron, y la RFC 9562 advierte que no se confíe en un UUID como prueba de permiso. Para un enlace de restablecimiento de contraseña, una sesión o una clave de API, usa un token aleatorio de al menos 128 bits y guarda en el servidor solo su hash.
En la forma habitual xxxxxxxx-xxxx-Vxxx-Nxxx-xxxxxxxxxxxx, el dígito V es la versión y los primeros bits de N son la variante: 8, 9, a o b para la estructura de la RFC 9562 que usan casi todos los UUID. Las versiones 1 y 6 contienen un contador de 60 bits de intervalos de 100 nanosegundos desde el 15 de octubre de 1582, junto con un ID de nodo, que originalmente era la dirección MAC de la tarjeta de red. La versión 7 contiene milisegundos Unix. Las versiones 3 y 5 son hashes de un nombre y la versión 4 es aleatoria, así que no contienen nada que decodificar.
Los diez primeros caracteres de un ULID son su timestamp. El inspector también acepta UUID sin guiones, entre llaves o con el prefijo urn:uuid:.
Cada bit aleatorio sale de crypto.getRandomValues, el generador de números aleatorios criptográfico del navegador. No se pide nada a ningún servidor y no se guarda nada.
Los UUID versión 7 generados en el mismo milisegundo mantienen el timestamp y suman un incremento aleatorio a los 74 bits aleatorios, que es el método monótono que describe la RFC 9562, así que un lote siempre queda ordenado tal como se generó. Los ULID generados en el mismo milisegundo suman uno a la parte aleatoria, como describe la especificación de ULID. Ese orden se cumple para los ID de esta página. Los ID generados en máquinas distintas en el mismo milisegundo no siguen ningún orden concreto. Los caracteres de un Nano ID se eligen descartando los bytes aleatorios que caen fuera del alfabeto, así que todos los símbolos tienen la misma probabilidad.
La versión 7 encaja mejor como clave primaria cuando quieres que las filas nuevas queden juntas en el índice y no te importa que el ID muestre su momento de creación. La versión 4 es la opción cuando el ID no debe revelar nada. Ambas tienen 128 bits y caben en la misma columna uuid.
Es posible, pero demasiado improbable como para tenerlo en cuenta. Un UUID versión 4 tiene 122 bits aleatorios, así que hacen falta unos 2,7 trillones (2,7 × 10^18) antes de que la probabilidad de una sola repetición llegue al 50 %. El riesgo real es una fuente aleatoria débil, y por eso esta herramienta usa el generador criptográfico del navegador.
No, aunque se parecen. Ambos tienen 128 bits y empiezan con un timestamp de 48 bits en milisegundos, así que los bits de un ULID caben en una columna UUID de 128 bits. Un ULID no tiene campos de versión ni de variante, por lo que la RFC 9562 no lo define como UUID, y su forma de texto usa Crockford Base32 donde un UUID usa hexadecimal.
Sí en las versiones 1, 6 y 7 de UUID y en los ULID, que contienen un timestamp. Pega el valor en el inspector para verlo como fecha. Un UUID versión 4 es aleatorio y no contiene ninguna hora.