Encoders & Utilities

UUID Generator

Generate UUID v1, v4, v7, NIL, or MAX in batches. Toggle uppercase, braces, or no-dash format.

Version

When to use which version

  • v1 — time-based + MAC node. Good when ordering matters and you need debuggable insertion order. Leaks MAC/host info if real MAC is used; we generate a random multicast-bit node so no real hardware is exposed.
  • v4 — random. Default choice. Collision-resistant (2¹²² entropy), good for distributed systems where ordering doesn't matter. Bad for DB primary keys at scale (random order kills B-tree locality).
  • v7 — time-ordered (RFC 9562, 2024). 48-bit Unix-ms timestamp prefix → lexicographically sortable + index-friendly. Recommended for new DB primary keys. Use this if you can.
  • NIL00000000-0000-0000-0000-000000000000. Sentinel/placeholder value.
  • MAX — all-ones UUID (RFC 9562). Useful as "infinity" sentinel paired with NIL.

About this tool

UUID Generator emits 128-bit Universally Unique Identifiers conformant with RFC 9562 (the 2024 update of the original RFC 4122). Five variants are supported: v1 (time + MAC, predictable across time), v4 (random — the most common), v7 (time-ordered random, the modern default for database keys), NIL (all-zero placeholder), and MAX (all-FF — useful as a "maximum" boundary in range queries). Generate one or up to 1000 at once.

All randomness comes from crypto.getRandomValues() — the same browser CSPRNG used by TLS. UUIDs never repeat in practice: v4's 122 bits of randomness give a collision probability so low that generating one billion per second for 85 years has about a 50% chance of a single collision (the "birthday bound" for 122 bits). v7 reduces randomness to 74 bits in exchange for time-ordering, which is still collision-safe at any realistic scale.

When to use this tool

  • Generating a sample database ID for tests. Faster than running your ORM's generator.
  • Picking the right version. v7 sorts by time when used as a primary key — much better for B-tree indexes than v4. Use v4 only when you actively want to hide order.
  • Seeding fixtures. 100 distinct UUIDs in one click for a test data set.
  • Inspecting a UUID format. Validate that a string you received is actually a valid UUID and find out which version.

About v7 vs v4

UUID v7 was standardised in 2024 specifically to fix v4's anti-database-friendly randomness. v7 has the timestamp (48 bits, millisecond resolution) in the high bits, so freshly-generated UUIDs sort lexically by creation time. This keeps a B-tree index "tight" (new inserts cluster at one end) instead of scattering across pages. For new applications, v7 is the new default; v4 stays useful only when you specifically want unguessability of order.

Frequently asked questions

What is the difference between v4 and v7 UUIDs?

v4 is 122 bits of random data — the order of two v4 UUIDs is meaningless. v7 embeds a 48-bit Unix millisecond timestamp in the high bits, so v7 UUIDs generated later sort after ones generated earlier. For database primary keys, v7 is dramatically friendlier to B-tree indexes; v4 spreads writes across the whole index and causes more page splits.

Are UUIDs really unique?

Effectively yes. For v4, with 122 bits of randomness, you would need to generate ~2.7 × 10^18 UUIDs before having a 50% chance of one collision. The world generates trillions per year and collisions are not a real problem. v7 with 74 random bits is still safe to the tune of ~1.5 × 10^11 per millisecond. NIL UUID (00000000-...) is the one exception and is reserved.

Why do some UUIDs have braces around them?

A Microsoft convention — Windows COM and .NET often display GUIDs as {xxxxxxxx-xxxx-...}. The braces are not part of the value, just decorative. Most other ecosystems (Linux, JSON APIs, JavaScript) write UUIDs without braces. Our toggle lets you produce either format; switch as needed when interoperating with Windows-heavy stacks.

Can I use these as database primary keys?

Yes — UUIDs are widely used as PKs. For new tables, prefer v7 (or ULID, a related format) so that the index stays compact. v4 is technically fine but causes more write amplification on B-tree indexes due to random scatter. PostgreSQL, MySQL 8+, and SQLite all have native or near-native UUID support; in MySQL pre-8, store as BINARY(16) for compactness.