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.

UUIDs are not secrets. 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.

UUIDv7 is the answer to "v4 vs ULID." 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). The "ULID vs UUID" debate that consumed teams in 2019-2022 is essentially resolved — pick v7 unless you have an explicit need for ULID's Crockford-base32 alphabet or its case-insensitivity. 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 (the "birthday paradox" — collision probability rises with the square root of the namespace). 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. UUIDs aren't secrets. An access-token-shaped identifier in a URL that's a UUID isn't safer than one that's a serial integer — both leak when logged, both end up in browser history, both are guessable if the URL is shared. Use UUIDs for identifiers; use cryptographically-signed tokens (or random opaque tokens stored in a database) for access control. 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 (the same external resource always maps to the same internal UUID) — 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.

UUID Generator

Generate RFC 4122 UUIDs (v4 random or v7 time-ordered). Batch up to 100. Cryptographically secure.

Version

Count (1-100)

Output

What is this for?

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. Useful when you need an ID before talking to a database, when you want to avoid leaking row counts, or when an ID has to be generated client-side and synced later. 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.

When to use it

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.

v4 vs v7 — which should I use?

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.

Common gotchas

UUIDs are not secrets. 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.

Expert notes

UUIDv7 is the answer to "v4 vs ULID." 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). The "ULID vs UUID" debate that consumed teams in 2019-2022 is essentially resolved — pick v7 unless you have an explicit need for ULID's Crockford-base32 alphabet or its case-insensitivity.
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 (the "birthday paradox" — collision probability rises with the square root of the namespace). 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.
UUIDs aren't secrets. An access-token-shaped identifier in a URL that's a UUID isn't safer than one that's a serial integer — both leak when logged, both end up in browser history, both are guessable if the URL is shared. Use UUIDs for identifiers; use cryptographically-signed tokens (or random opaque tokens stored in a database) for access control.
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 (the same external resource always maps to the same internal UUID) — 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.