Generador de UUID

Genera UUIDs en tu navegador — v4 aleatorio o v7 ordenado por tiempo, uno a uno o en lote. No se sube nada, sin inicio de sesión, sin rastreo.

Opciones
Versión

Un UUID por línea, en un único bloque para copiar fácilmente.

Consejo: Ctrl/⌘+A selecciona todo, Ctrl/⌘+C copia.

Los UUIDs son únicos a efectos prácticos, no únicos garantizados. La generación se ejecuta por completo en tu navegador usando crypto.getRandomValues; no se hacen llamadas de red.

About this tool

UUID generates RFC 4122 version 4 (random) and version 7 (time-ordered) UUIDs in your browser. Version 4 is the classic 128-bit random identifier with 6 fixed bits and 122 random bits — the right choice when you need an opaque, unguessable ID with no ordering guarantee. Version 7 encodes a Unix-millisecond timestamp in the high 48 bits and uses the remaining bits for randomness, giving you IDs that are still globally unique but sort lexicographically by creation time — the right choice for database primary keys, log lines, and event streams where you want chronological locality without giving up the uniqueness properties of v4.

When to use it

  • Generating primary keys for a new database row when you don't want to expose row counts
  • Creating opaque, unguessable identifiers for user-facing tokens (password reset links, share IDs)
  • Building the event ID for a log entry where you want chronologically-ordered IDs without a coordinated counter
  • Migrating from auto-increment IDs to distributed-friendly identifiers

When not to use it

  • You need a sortable ID for OLTP — v7 is sortable but you may want ULID or a similar format if your stack already understands it
  • You need cryptographic nonces or session tokens — use the password generator with sufficient length, or a CSPRNG directly, instead
  • You need a NameID (v5) or a hash-based UUID — this generator is v4 and v7 only

Frequently asked questions

Is the v4 random source cryptographically secure?

Yes. The implementation calls crypto.getRandomValues, which is the browser's CSPRNG. The 122 bits of randomness come from that source — they are not predictable from outside the browser tab.

Should I use v4 or v7?

Use v4 when you need an opaque, unguessable ID with no ordering guarantee. Use v7 when you want IDs that sort by creation time, which is useful for database indexes and event streams. The trade-off is that v7 leaks the creation time to anyone who can read the ID.

Can two v4 UUIDs collide?

Theoretically yes, practically no. With 122 bits of randomness, the probability of a collision is approximately 1 in 2^61 even after generating a billion UUIDs per second for a hundred years. You will not see a collision in any realistic workload.

← Back to the homepage · More guides · More from the blog