UUID Generator

UUID Generator Online (v4, v7, v1, v3, v5, v6) — RFC 4122 / RFC 9562

Generate any UUID version instantly in your browser — no server, no signup required. Works as a GUID generator too. Bulk up to 100 at once. Copy with one click.

UUID Anatomy

Each UUID follows the pattern xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The highlighted digits below reveal what each version encodes.

Version 4 — Random

4  Version digit — all other bits are random.

Version 7 — Unix ms Timestamp + Random (recommended)

■ Unix ms timestamp (48 bits)  ·  7 Version digit  ·  random suffix

Version 1 — Gregorian Timestamp (legacy)

■ Timestamp split across 3 fields (time_low · time_mid · time_hi)  ·  1 Version digit

How to Generate a UUID

1. Choose a version — Version 7 is the recommended default. Pick Version 4 for pure randomness, or v3/v5 for deterministic name-based IDs.
2. Set bulk count — Enter any number from 1 to 100 to generate multiple UUIDs at once (v3/v5 always generate one).
3. Click "Generate New" — or press Ctrl+G (⌘+G on Mac) for instant generation from anywhere on the page.
4. Copy your UUID — Click the UUID directly, press Shift+Enter, or use the Copy All button to grab a newline-separated list.

Why UUID v7 Is the Modern Default for Databases

UUID v7 encodes a 48-bit Unix millisecond timestamp as the most-significant bits of the identifier. This single design decision has a profound impact on database performance:

B-tree index locality. In PostgreSQL, MySQL, and most SQL databases, primary keys are stored in a B-tree index. When you insert rows with random UUIDs (v4), every new row lands at a random position in the tree, causing page splits and cache misses across the entire index. With v7, new rows always append near the end of the index (most-recent timestamp = highest value), which means far fewer page splits and much better buffer cache utilization.

No separate sequence column needed. A common pattern with UUID v4 is to pair it with a BIGSERIAL or AUTO_INCREMENT column just to get insertion-order sorting:

-- With UUID v4 you often need this:
id BIGSERIAL PRIMARY KEY,
uuid UUID UNIQUE NOT NULL DEFAULT gen_random_uuid()

UUID v7 eliminates this entirely — the UUID itself is already time-ordered, so you can use it directly as the primary key without any performance penalty:

-- With UUID v7 this is enough:
id UUID PRIMARY KEY DEFAULT gen_uuid_v7()

v7 vs v1. UUID v1 also embeds a timestamp, but it splits the timestamp across three non-contiguous fields in little-endian order, so the string does not sort chronologically. UUID v7 places the full timestamp in the leading bits, so lexicographic string sort equals chronological sort — no special handling required.

v7 vs v6. UUID v6 fixes the v1 sorting problem by reordering the timestamp fields, but it still uses the Gregorian epoch (100-nanosecond intervals since 1582). UUID v7 uses the Unix epoch (milliseconds since 1970), which is natively supported by every programming language and database. v7 is the practical choice for new projects.

UUID Version Comparison

What Is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit label standardized by RFC 4122 (versions 1–5) and RFC 9562 (versions 6–8). It is represented as 32 hex digits in the format xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M encodes the version and N the variant. Microsoft's GUID (Globally Unique Identifier) uses this exact same format — UUID and GUID are interchangeable.

The probability of collision between two random UUID v4 values is negligible: you would need to generate roughly 2.71 quintillion UUIDs to reach a 50% chance of a duplicate. UUID v7 adds a millisecond timestamp prefix, making collisions within the same millisecond essentially impossible in practice.

Common Use Cases

• Database primary keys (new systems) — Use UUID v7. Its timestamp prefix gives B-tree index locality without a separate sequence column. Same global uniqueness as v4, with the insertion-order benefit of a BIGSERIAL.
• Database primary keys (existing v4 systems) — UUID v4 works fine for existing systems. Migrating to v7 is worthwhile for high-write tables with performance bottlenecks.
• Session tokens and API request IDs — UUID v4 or v7 for non-guessable identifiers with full randomness.
• Idempotency keys in payment processing — Send a UUID with each payment request so your backend can safely retry without double-charging. Standard practice in Stripe, Adyen, and similar APIs.
• Deterministic IDs from known data — Use UUID v5 (SHA-1) when you need the same UUID every time for a given namespace + name combination, for example hashing a URL or email address into a stable identifier.
• File names for user uploads — Replace original filenames with a UUID before storing in S3 or GCS to avoid path collisions and prevent filename enumeration.
• Correlation IDs in distributed tracing — Attach a UUID to every log entry and propagate it across service calls to reconstruct the full request trace.

Frequently Asked Questions

Is a UUID the same as a GUID?

Yes — GUID is simply Microsoft's name for the same format defined by RFC 4122. They are fully interchangeable. If you need a GUID generator for .NET, SQL Server, or Windows APIs, this tool produces valid GUIDs.

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

For new systems, yes. UUID v7 gives you global uniqueness (no coordination between shards), chronological sort order, and good B-tree insert performance — essentially the best of both worlds between a sequential integer and a random UUID. The only trade-off is a slightly larger storage footprint (16 bytes vs 8 for BIGINT).

When should I use UUID v4?

Use v4 when you need maximum randomness and do not care about insert order — for example, session tokens, API keys, or one-off identifiers where the timestamp embedded in v7 would be a privacy concern.

When should I use UUID v3 or v5?

Use v5 (SHA-1) when you need a deterministic UUID from a known input, such as generating a stable ID from a URL or email address. Use v3 (MD5) only when you need to interoperate with a system that already uses v3; SHA-1 is cryptographically stronger.

When should I use UUID v6?

UUID v6 is a drop-in replacement for v1 with better sort order. Prefer v7 for new projects; v6 is mainly useful when migrating existing v1 deployments that need sortable UUIDs without changing the epoch.

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

Yes. This generator uses crypto.randomUUID() and crypto.getRandomValues(), which call the OS CSPRNG — the same entropy source that generates TLS private keys. All generation happens locally in your browser; nothing is sent to any server.

What does the entropy value mean?

Entropy measures the unpredictability of the UUID in bits. Version 4 has 122 bits of random entropy (the remaining 6 bits are fixed version/variant markers). Versions 1, 6, and 7 have ~74 bits of random entropy — the rest is determined by the timestamp. Versions 3 and 5 are fully deterministic (zero entropy) — the output is always the same for the same namespace + name input.

Resources

• IETF RFC 9562 — New UUID Formats — The updated specification defining UUID versions 6, 7, and 8.
• IETF RFC 4122 — UUID URN Namespace — The original specification defining versions 1–5.
• Wikipedia — Universally Unique Identifier — History, versions, and adoption across databases and distributed systems.