Skip to main content

UUID Generator

What it does

The UUID Generator produces cryptographically random identifiers in two versions: v4 (fully random, 122 bits of entropy) and v7 (time-sortable, with the leading 48 bits encoding the millisecond timestamp). Bulk generation supports up to 200 IDs at a time, with a toggle for uppercase output. There is also a NIL preset (00000000-0000-0000-0000-000000000000) for tests, sentinels, and “intentionally empty” markers. All entropy comes from crypto.getRandomValues — never Math.random, which is not suitable for IDs that need to be unguessable.

Common situations

You’re seeding a test database with realistic-looking primary keys. Generating a batch of v7 UUIDs gives you time-sortable IDs that will behave like production data — important if your test queries rely on insertion order.

You’re producing API documentation that shows example response payloads. Real responses include real-looking UUIDs; placeholders like xxx-xxx-xxx look unprofessional. Generate a batch of v4 UUIDs and use them as documentation examples.

You’re picking the version for a new database table. v4 is the historic default; v7 is increasingly the better choice because it sorts by creation time, which keeps B-tree indexes happy and makes “give me the most recent N rows” queries trivial. The decision is per-table; the tool generates both for evaluation.

You’re configuring a webhook secret, an OAuth state parameter, or any one-off opaque identifier. A fresh v4 UUID is the right shape — unguessable, well-distributed, and recognisable as an identifier rather than a meaningful value.

You’re investigating a UUID format encountered in production logs and want to know which version it is. The version digit is at position 13 (0-indexed): xxxxxxxx-xxxx-Vxxx-.... V=4 is random; V=7 is time-sorted. Generating both versions for comparison shows the visual difference.

What you need to know

v4 UUIDs use the browser’s built-in crypto.randomUUID() where available, which produces a UUID conforming to RFC 9562 with version bits and variant bits set correctly. The 122 random bits come from the same CSPRNG that backs cryptographic operations, so collision risk is negligible — generating a billion v4 UUIDs per second for a hundred years has roughly a 50% chance of one collision.

v7 UUIDs are hand-rolled because most browsers do not yet ship a native generator. The implementation follows the RFC: 48 bits of millisecond timestamp, 4 version bits set to 0111, 12 bits of randomness, 2 variant bits set to 10, and 62 more bits of randomness. The result sorts lexicographically in the same order it was created — the property that makes v7 useful for database work.

NIL is the all-zeros UUID (00000000-0000-0000-0000-000000000000), formally defined as a “this UUID is intentionally empty” marker. Some systems use it as a sentinel; some reject it. Knowing about it is useful even if you rarely emit it.

Why v7 over v4 for database keys? v4 IDs are random — inserts scatter across the index, causing B-tree fragmentation and forcing pages to be loaded from disk on every insert. v7 IDs sort by creation time — inserts append to the rightmost index page, which stays hot in memory. The difference matters at scale: a high-throughput v4-keyed table can spend 60%+ of its time on index maintenance; the same table v7-keyed can be 5%.

Why v4 over v7 for security? v7 leaks the creation timestamp. If knowing when a token was generated is sensitive (session tokens, magic links, password reset tokens), v4 is safer. v4 reveals nothing about the generator’s state.

The historical versions v1 (timestamp + MAC address), v2 (DCE security), v3 (MD5-based namespace), v5 (SHA1-based namespace), and v6 (reordered v1) exist but are rarely the right answer in 2026. v4 and v7 cover almost every modern use case; the others are legacy compatibility.

The string form is 36 characters with hyphens, 32 without. Most APIs accept either; database UUID columns store the underlying 128 bits regardless of which form you pass in.

Frequently asked questions

What is a UUID?

A 128-bit identifier formatted as xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Used as primary keys, session identifiers, and unique opaque references where collision risk needs to be negligible.

What’s the difference between UUID v4 and v7?

v4 is fully random; v7 starts with a 48-bit millisecond timestamp followed by random bits. v4 is the historic default; v7 is increasingly preferred for database keys because it sorts by creation time.

Should I use v4 or v7 for new projects?

For database primary keys: v7. The time-sortable property keeps indexes performant and makes “newest first” queries trivial. For session tokens, magic links, or anywhere the timestamp leak is a security concern: v4.

What’s a NIL UUID?

The all-zeros UUID (00000000-0000-0000-0000-000000000000). A formally defined “intentionally empty” marker. Some systems use it as a sentinel; some reject it as invalid input.

Are UUID collisions possible?

Theoretically yes, practically no for v4 and v7 with proper random sources. The probability of a v4 collision in a billion-UUID-per-second system over a hundred years is about 50%. For normal-scale systems, treat collisions as impossible.

Why does my UUID generator return the same value every time?

You are using Math.random instead of crypto.getRandomValues. Math.random is not cryptographically secure and can be predictable. Always use crypto.getRandomValues (browser) or your platform’s CSPRNG.

Can I create custom UUIDs from a specific input?

Yes — UUID v3 and v5 are deterministic, generated from a namespace plus a name via MD5 (v3) or SHA1 (v5). Same input produces same output. Useful for content-addressed IDs (deduplication, cache keys) but rarely the right answer for mainstream use.

How do I generate a UUID in code?

JavaScript: crypto.randomUUID() for v4. Python: uuid.uuid4(). Node: crypto.randomUUID(). Most languages have a built-in generator. For v7, you typically need a small library or hand-rolled implementation.

Will UUIDs run out?

122 bits of randomness produces 5.3 × 10³⁶ possible values. Assigning every atom on Earth a unique UUID would use a tiny fraction of the space. There is no realistic exhaustion scenario.

Common problems

Problem: UUIDs in my database don’t seem to be sorting in insertion order.

You are using v4 (random). v4 IDs do not sort by time. Switch to v7 for new inserts; for existing data, you cannot retroactively reorder. Some databases support sequential UUIDs as a built-in feature.

Problem: Generated UUIDs occasionally have a 6 or 8 in the third group instead of 4.

That is correct — the 13th character (after the second hyphen) is the version digit. v4 produces 4; v7 produces 7. The 6 and 8 are valid placements only for v6 (rare) and v8 (custom). If you see them, you may be looking at a non-standard format.

Problem: UUID generation is slow when generating thousands at once.

Browser crypto.getRandomValues is fast (microseconds per call), but loop overhead dominates at very high volume. For batch generation of millions, server-side or CLI tools are faster.

Problem: My API rejects UUIDs without hyphens.

Some validators require the canonical hyphenated form (xxxxxxxx-xxxx-...). Insert hyphens at positions 8, 13, 18, 23 if your input is unhyphenated. Or normalise before sending.

Problem: Two services on the same machine generated colliding UUIDs.

Almost certainly a bug — both services using a non-cryptographic PRNG seeded the same way. UUID generation must use crypto.getRandomValues or platform CSPRNG. Check both services’ UUID library.

Quick guides

JavaScript / Node: crypto.randomUUID() for v4. For v7, use the uuidv7 npm package or hand-roll. Most production code reaches for uuid or nanoid for finer control.

PostgreSQL: uuid_generate_v4() from the uuid-ossp extension, or gen_random_uuid() (built-in). For v7, use the pg_uuidv7 extension or generate at the application layer.

Python: uuid.uuid4() for v4. v7 needs a library — uuid7 is commonly used. Avoid uuid.uuid1() unless you specifically need MAC-address-based IDs (rare).

Tips

  • v4 is right when you need unguessable IDs — session tokens, magic links, public-facing identifiers where leaking the next ID’s value would be a security issue.
  • v7 is right when you need sortable IDs — primary keys, log entries, anything where “most recent” is a common query and you want the index sort order to match insertion time.
  • Avoid v1 (timestamp + MAC address). It leaks the generating machine’s MAC address in the ID, which is a privacy concern and rarely useful.
  • v3 and v5 (namespace-based) are deterministic — same input produces same output. Useful for content-addressed IDs (deduplication, cache keys), niche otherwise.
  • The string form is 36 characters with hyphens, 32 without. Most APIs accept either; database UUID columns store the underlying 128 bits regardless of how you pass them in.
  • Never use Math.random for UUID generation. Use crypto.getRandomValues (browser) or your platform’s CSPRNG.

Related tools in this suite

The natural pairing is the Hash Generator — UUIDs and hashes are the two ways software produces “stable identifier from inputs”, and the right choice depends on whether the identifier needs to be reproducible (hash) or unique-per-call (UUID). The Mock JSON Generator emits UUIDs as part of its output for the entity types that have an id field.

Take it further

ID strategy is a system-wide decision: which version, where they are minted, whether they are exposed in URLs, how they interact with auditing and access control. The systems we build treat ID generation as a deliberate choice rather than a default — switching from v4 to v7 mid-project, or back-filling tables with sortable IDs, is the kind of work that pays back forever.