Should I use UUID v7 instead of auto-increment for a primary key?

For new systems, yes. It gives you global uniqueness without cross-shard coordination, chronological ordering, and good insert performance — the best of both worlds.

When should I use UUID v4?

When you need maximum randomness and don't care about insertion order — session tokens, API keys, or anywhere v7's embedded timestamp would be a privacy concern.

When should I use UUID v3 or v5?

Use v5 (SHA-1) for a deterministic UUID generated from a known input, like a URL or an email address. Use v3 (MD5) only to interoperate with legacy systems that already rely on it.

Is it safe to generate a UUID in the browser for production use?

Yes. This tool uses `crypto.randomUUID()` and `crypto.getRandomValues()`, which draw from the operating system's CSPRNG. Generation happens entirely locally — nothing is sent to a server.

How random is a UUID v4, really?

Extremely: 122 random bits, meaning you'd need roughly 2.71 quintillion UUID v4s generated before a 50% chance of a single collision. In practice, collisions aren't a real-world concern.

UUID Generator

Generate UUID v4, v7, v1, v3, v5 or v6 instantly in your browser. RFC 4122 / RFC 9562 compliant. Bulk generation, session history, and one-click copy.

Updated April 2026

CONFIGURATION

UUID Version

v7 embeds Unix ms timestamp as a prefix — UUIDs sort by creation time. No separate sequence column needed for DB insert performance.

Bulk Generation LIMIT: 100

Quick Tip

Use Ctrl+G to regenerate instantly. · Shift+Enter to copy.

GENERATED OUTPUT

Ready for production use

Click "Generate New" to create a UUID

How to generate a UUID

Any version, in bulk, instantly

1. Pick a version

v7 is the recommended default. Use v4 for pure randomness, or v3/v5 for deterministic IDs.

2. Set the quantity

Generate 1 to 100 at once (v3/v5 always produce a single UUID, since they're deterministic).

3. Copy it

Click a UUID, press `Shift+Enter`, or use "Copy All" for the whole batch.

What this UUID generator does

RFC 4122 and RFC 9562, every version

v1 through v7 in one place

Random, name-based, or time-ordered — no switching tools.

Bulk generation

Up to 100 UUIDs at once, each copyable individually or as a block.

`crypto.randomUUID()` under the hood

Uses the operating system's CSPRNG — the same entropy source behind private TLS keys.

Works as a GUID generator too

Microsoft's GUID is the same RFC 4122 format — fully interchangeable.

Anatomy of a UUID

Every UUID follows `xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx`

Version

What M reveals

v4 — `550e8400-e29b-41d4-a716-446655440000`

Version digit 4 — every other bit is random

v7 — `0191d2a0-1234-7a3f-9c2d-4f8e1b5a6c3d`

48-bit Unix ms timestamp + version digit 7 + random suffix

v1 — `6ba7b810-9dad-11d1-80b4-00c04fd430c8`

Gregorian timestamp split across 3 fields + version digit 1

When you'll reach for a UUID generator

The most common scenarios people use this for

Primary keys in new systems

UUID v7 — B-tree index locality without a separate sequence column.

Session tokens and request IDs

v4 or v7 for unguessable identifiers with full randomness.

Idempotency keys for payments

Send one UUID per request so the backend can reject duplicates — the pattern Stripe and Adyen use.

Deterministic IDs from known data

v5 (SHA-1) for the same UUID every time, given a namespace + name — like a URL or an email address.

Filenames for uploads

Replace the original filename with a UUID before saving to S3 or GCS.

Correlation IDs for distributed tracing

Attach one to every log entry and propagate it across services to reconstruct a request's path.

Common mistakes

Using v4 when v7 would perform better

v4 scrambles insertion order in the index, causing page splits on high-volume SQL databases.

Assuming v1/v6 don't leak information

Both embed a creation timestamp — avoid them when the timing itself needs to stay private.

Expecting v3/v5 to be random

They're deterministic by design: the same namespace + name always produces the same UUID.

Why UUID v7 is the modern default

v7 encodes a 48-bit Unix millisecond timestamp in the most significant bits. That keeps new rows inserted near the end of a B-tree index instead of scattered across it, removing the usual need for a separate BIGSERIAL column just for ordering.

The performance gap is measurable, not theoretical: published benchmarks on a 50-million-row table show bulk inserts finishing in roughly 1.8 minutes with v7 versus about 20 minutes with v4, with a ~25% smaller index and range scans running about 3x faster.

UUID version comparison

Which one to use, and when

Algorithm

Gregorian timestamp

Random

Name-based SHA-1

Unix ms timestamp

Embedded timestamp

yes (scrambled)

yes (sortable)

Insert performance

poor

—

best

Best for

legacy systems

general use

stable name-based IDs

new primary keys

Frequently asked questions

Yes — GUID is Microsoft's term for the same format defined by RFC 4122. They're fully interchangeable, and this generator produces GUIDs that are valid for .NET, SQL Server, or Windows APIs.

References

IETF RFC 9562 — New UUID Formats

The updated specification defining UUID versions 6, 7 and 8.

IETF RFC 4122 — A UUID URN Namespace

The original specification defining versions 1 through 5.

Wikipedia — Universally Unique Identifier

History, versions, and adoption across databases and distributed systems.