UUID v4 Generator

What is UUID v4?

UUID v4 is a 128-bit random identifier with 122 random bits. The remaining 6 bits mark the version and variant.

Example: 550e8400-e29b-41d4-a716-446655440000

It's used for database records, API resources, distributed systems, and test data because it can be generated independently without a central counter. Collision probability is negligible with a CSPRNG.

GUID vs UUID v4

Same thing in practice. GUID is Microsoft's term, UUID is the RFC 9562 standard. Guid.NewGuid() in .NET generates a UUID v4.

Why use UUID v4?

With auto-increment IDs, you need a central database to assign the next number.

In distributed systems — multiple services, shards, offline clients — that creates a bottleneck.

UUID v4 removes the coordination. Any service generates an ID independently, with 5.3×10³⁶ possible values.

Who uses UUID v4?

• Backend: record IDs, jobs, correlation IDs
• Frontend: temporary client-side IDs before server save
• Database: primary keys where independent generation helps
• QA: unique test data without coordination

How to generate UUID v4

One library call. Format: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

// C# - .NET
Guid.NewGuid()

// JavaScript
crypto.randomUUID()

# Python
import uuid
uuid.uuid4()

-- PostgreSQL
SELECT gen_random_uuid();

1. Generate with CSPRNG — never Math.random()
2. Send as string in JSON / REST / GraphQL
3. Store as native uuid or BINARY(16) — not VARCHAR(36)

You can generate it before the DB row exists — that's the point for distributed systems.

How many bits are random in UUID v4?

A UUID v4 is 128 bits, but exactly 122 bits are random.

The remaining 6 bits are reserved:

• Version: 4 bits — set to 0100 to identify v4
• Variant: 2 bits — set to 10 for RFC 9562 variant

These bits tell software how to interpret the UUID. The version distinguishes v4 from v1, v5, v7, while the variant identifies the layout.

This is why v4 does not provide full 128 bits of randomness.

With 122 random bits, UUID v4 has:

2^122 = 5.3 × 10³⁶ possible values.

Is UUID v4 suitable for databases?

Yes, but whether it is a good primary key depends on workload, index design, and storage.

Advantage: The application generates the value without contacting the database. Useful for distributed systems, APIs, offline apps, data sync, and multiple services creating records independently.

Tradeoff: UUID v4 values are randomly distributed. In a B-tree index, sequential IDs insert near the end. Random v4 values target many different index pages. On large, write-heavy workloads, this can increase page splits, reduce locality, and increase cache and I/O.

That doesn't make v4 unsuitable. Many apps use it successfully. Impact depends on table size, write volume, indexing strategy, engine, and hardware.

Database-specific considerations

When to consider alternatives

• Extremely high-volume writes — random v4 has less favorable index locality than sequential or v7
• Chronological ordering is required — v4 has no creation-time info
• Storage is constrained — 4-byte int is smaller than 16-byte UUID
• Compact URL needed — Nano ID is shorter than 36-char UUID

These are reasons to evaluate alternatives, not to reject v4 outright.

Is UUID v4 sortable?

Not by creation time.

UUID v4 values are randomly generated, so natural ordering has no relationship to creation time. Sorting does not produce chronological order.

If you need to query or sort by creation time, add a separate created_at timestamp.

Alternatively, use a time-ordered ID like UUID v7 or ULID when embedding time is useful.

Is UUID v4 suitable for URLs?

Yes. UUID v4 is commonly used as a resource identifier in URLs and APIs.

Example: https://example.com/orders/550e8400-e29b-41d4-a716-446655440000

Unlike /orders/12345, a UUID v4 does not reveal an obvious sequence that can be incremented to discover neighboring IDs.

A properly generated UUID v4 is also difficult to guess because of its large random space. However, this should not be treated as a security mechanism.

If a URL identifies a protected resource, the server must authenticate and authorize the request regardless of guess difficulty.

Length tradeoff: 36 characters is long. Nano ID may be preferable when URL length matters.

UUID v4 and security

UUID v4 should be treated as an identifier, not as a password, session credential, or authorization mechanism.

A properly generated UUID v4 has 122 random bits and is extremely difficult to guess. Useful where accidental discovery or enumeration is a concern.

However, uniqueness and unpredictability are different properties.

• Uniqueness: independently generated IDs are extremely unlikely to collide
• Unpredictability: attacker cannot practically predict a valid ID

For authentication credentials, password-reset tokens, session tokens, API secrets, or other security-sensitive values, use purpose-built cryptographic token mechanisms — not UUID v4.

Comparison with other identifiers

The UUID family includes several versions for different requirements:

• UUID v1 — timestamp-based, historically includes node info
• UUID v3 — deterministic, name-based using MD5
• UUID v4 — random, 122 random bits
• UUID v5 — deterministic, name-based using SHA-1
• UUID v6 — reordered, time-ordered based on v1 structure
• UUID v7 — Unix timestamp + random, sortable by creation time
• ULID — 128-bit, timestamp + 80 bits randomness
• Nano ID — compact, configurable length/alphabet, not a UUID

Comparison table

*UUID v1 contains a timestamp, so fields can be ordered by creation time per defined layout. Not a guarantee of strict monotonic ordering.

UUID v4 vs UUID v7

Both are useful, but solve slightly different problems.

UUID v4 is about independent random generation. Simple, widely supported, does not expose creation-time information.

UUID v7 adds a Unix timestamp, making values generally sortable by creation time while retaining random data for remaining space.

UUID v7 is attractive for database-heavy apps where chronological ordering and index locality matter.

That does not make v7 a universal replacement. If you need a random ID without ordering, v4 remains straightforward and well-supported.

FAQ — UUID v4

What is a UUID v4?

UUID v4 is a randomly generated 128-bit identifier with 122 random bits. The 4 version bits are set to 0100 to mark it as v4. Most common UUID version, used for database records, API resources, test data, and distributed systems because it can be generated independently without a central counter. Example: 550e8400-e29b-41d4-a716-446655440000.

Is UUID v4 sortable?

No, not by creation time. UUID v4 values are random, so sorting does not produce chronological order. If you need time-ordered sorting, use UUID v7 or ULID, or store a separate created_at timestamp.

Is UUID v4 really unique? What is the collision chance?

Not mathematically guaranteed unique, but collisions are astronomically unlikely. With 122 random bits, there are 5.3×10³⁶ possible values. Probability of duplicate is negligible with CSPRNG. Do not use Math.random().

Is UUID v4 secure? Can I use it for passwords or tokens?

No. UUID v4 is an identifier, not a security credential. While 122 random bits are hard to guess, do not use for passwords, session tokens, password-reset tokens, or API secrets. Use purpose-built cryptographic token mechanisms. Uniqueness ≠ unpredictability.

What is the difference between GUID and UUID v4?

For practical purposes same. GUID is Microsoft's historical term, UUID v4 is standards term. When people say GUID they usually mean random UUID v4. In .NET, System.Guid.NewGuid() generates a UUID v4. Generator creates RFC 4122 / RFC 9562 compliant UUID v4.

Should I use UUID v4 or UUID v7 for database primary keys?

Use v4 if you need max compatibility, pure randomness, no timestamp leakage. Use v7 if you need chronological ordering, better B-tree index locality, and time-sortable keys. For new high-write tables, v7 often performs better. For general-purpose IDs, v4 remains simplest.

What is the UUIDv4 Text Layout?

A UUID v4 string is 36 characters: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. 122 bits are random, 6 bits mark version and variant per RFC 9562.

What is the UUIDv4 Binary Bit Layout?

128 bits total, 122 random. 4 version bits set to 0100b, 2 variant bits set to 10b.