UUID Generator

V4 vs V7: which UUID to pick

A UUID (or GUID) is a 128-bit identifier — written as 32 hex digits in 5 groups, like 550e8400-e29b-41d4-a716-446655440000. They're collision-free across systems without coordination: any process anywhere can mint one and the chance of two ever colliding is effectively zero. This tool emits RFC 4122 / RFC 9562 compliant UUIDs in v4 (random) or v7 (time-ordered) form, generated with cryptographically-secure randomness in your browser.

Where UUIDs replace auto-increment

• Primary keys for distributed systems where you don't want to round-trip to the database for an ID.
• Idempotency keys for API requests (Stripe, payment providers, queue messages).
• File-upload identifiers, session tokens, correlation IDs in logs.
• Anywhere you'd otherwise expose an auto-incrementing ID and leak how many records you have.
• Test data — seed a hundred records with realistic identifiers in one click.

Random (v4) vs time-ordered (v7)

• v4 (random) — 122 bits of randomness, no embedded creation time. Use when you want zero correlation between IDs and creation order, or when the ID will live in a hash-map / non-clustered index where ordering doesn't matter.
• v7 (time-ordered) — 48-bit Unix-ms timestamp prefix + random tail. Default to this for new database primary keys. The timestamp prefix gives B-tree indexes locality (recent inserts go to the same pages, much better cache behaviour than v4), and IDs sort in roughly chronological order. Defined in RFC 9562 (May 2024) — supersedes ULID and v1/v6 for most use cases.

Identifiers are not secrets

• UUIDs are not access tokens. v4 has 122 bits of entropy and is unguessable, but the format itself doesn't authorize anything. Don't use a UUID as a session token or password-reset token unless you're treating it as a secret (HTTPS-only, time-limited, single-use).
• v7 leaks creation time. The first 48 bits encode the millisecond it was minted. Fine for internal IDs; bad if you don't want users to learn when records were created. Use v4 in that case.
• Index size matters. A UUID is 16 bytes vs 8 for a bigint — your B-tree indexes get bigger. Worth it for distributed/no-coordination, often not worth it for single-server apps with a sequential ID.
• v4 fragments database indexes. Random IDs scatter writes across the index, hurting page cache hit rate and write throughput. This is the original argument for v7.
• Don't use v1. The old time-and-MAC variant leaks the generating machine's MAC address. v7 is the modern replacement.
• Use crypto-secure randomness. This tool uses crypto.getRandomValues; never roll your own with Math.random — it's not random enough and IDs become predictable.

The ULID debate is over

For new systems in 2026, UUIDv7 (timestamp-prefixed + random tail) is almost always the right pick. It sorts in insertion order (preserving B-tree write locality), it's 128 bits (compatible with every UUID column), and the standard finally landed in RFC 9562 (May 2024). Pick v7 unless you have an explicit need for ULID's Crockford-base32 alphabet or its case-insensitivity.

Collision math, storage, and the other versions

• Collision math is forgiving but not infinite. v4 has 122 bits of entropy. Generating one billion UUIDs per second for 85 years gives you a 50% chance of a single collision. For practical web apps, collisions are mathematically impossible. For very-high-throughput pipelines (telemetry, IoT), v7's timestamp prefix actually reduces effective entropy in the random tail; check the design margin if you're at scale.
• v3 and v5 are for namespacing, not freshness. If you hash the same name in the same namespace with v5, you get the same UUID every time. Useful for deterministic ID generation — not useful as a primary key for new records. v3 uses MD5 internally and should not be used in new systems.
• Store as a 16-byte binary, not 36-character text. PostgreSQL's uuid type, MySQL's BINARY(16), and SQL Server's uniqueidentifier are 16 bytes. The 36-character text form is 2.25x larger and slower to compare. The only reason to store text is JSON columns or denormalised logs where humans read the values directly.

Five v7 IDs minted in the same millisecond

Set version v7 and count 5, then generate. All five UUIDs share their leading characters — something like 0191f2c9-8a3e-7… — because they were minted inside the same millisecond and v7 puts a 48-bit timestamp at the front; they sort in creation order. Switch to v4 and the five are completely unrelated. In either version the 13th hex digit is the version nibble (4 or 7) and the 17th is the variant (always 8–b).

Primary keys, collisions, tokens, and identical prefixes

v4 or v7 for a new database primary key? v7. The timestamp prefix gives B-tree indexes write locality (recent inserts cluster on the same pages) and rows sort roughly chronologically. Reach for v4 only when you specifically want IDs with no relationship to insertion time.

Do I need to check these against my database for collisions? No. v4 carries 122 bits of entropy — you would need to generate a billion per second for decades to reach a coin-flip chance of a single clash. They're minted with crypto.getRandomValues, not Math.random, so they aren't predictable either.

Can I use a UUID as a password-reset or session token? Only if you treat it as a secret — HTTPS-only, single-use, time-limited. The format authorises nothing on its own, and a v7's leading bits reveal exactly when it was created, which is fine for an ID but poor for a secret.

Why do my v7 UUIDs look almost identical? That's the design, not a bug. The shared prefix is the millisecond timestamp; only the tail is random. Generate a batch a second apart and the prefixes advance in order.

128 bits, five groups, and a version nibble

A UUID is 128 bits written as 32 hex digits, and the version determines where those bits come from. Version 4 is almost all randomness — 122 random bits, giving collision odds so remote you can mint billions without a central authority. Version 7, newer, prefixes a Unix-millisecond timestamp before the random bits, so v7 IDs sort chronologically — a big win as database primary keys because they don't scatter writes across an index the way v4 does. Versions 1 and 5 derive from MAC-address-plus-time and from hashing a name, respectively. The version and variant digits sit at fixed positions, which is how a decoder tells them apart.

The v4 fragmentation trap

Using random v4 UUIDs as database primary keys and then wondering why insert performance degrades. Because v4 is unordered, each new row lands at a random point in the index, fragmenting it; v7 (or an ordered ULID) fixes this by embedding time. The other misconception is treating UUIDs as secret — they are unique, not unguessable in a security sense, so never rely on one alone to protect a resource.

Related

Generate secrets with the password generator instead when unguessability matters, checksum content with the hash generator, and read v7's embedded time with the timestamp converter. Which version to pick: why UUID versions matter.