UUID Generator

About UUID Generator

How Does a UUID v4 Work?

A version 4 UUID follows the pattern xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, where the "4" in the third group marks it as version 4, and the leading bits of "y" are set to 10 in binary to indicate the RFC 9562 variant. The remaining 122 bits come from a cryptographic random number generator. RFC 9562 (published May 2024 by the IETF) superseded the original RFC 4122 and formalised UUID versions 6, 7, and 8 alongside the existing v1 through v5.

Worked example: Take the UUID 550e8400-e29b-41d4-a716-446655440000. The third group starts with 4, confirming version 4. The first hex digit of the fourth group is a (binary 1010), where the leading 10 bits confirm the RFC 9562 variant. Every other character is random.

Section	Characters	Bits	Content
time-low	8 hex chars	32	Random (not a timestamp in v4)
time-mid	4 hex chars	16	Random
time-hi-and-version	4 hex chars	16	4 bits = version (0100), 12 bits random
clock-seq-and-variant	4 hex chars	16	2 bits = variant (10), 14 bits random
node	12 hex chars	48	Random

UUID Versions Compared

RFC 9562 defines eight UUID versions in total. The table below covers the five most commonly encountered.

Version	Basis	Sortable	Privacy	Status
v1	Timestamp + MAC address	Partially	Leaks MAC address and creation time	Legacy
v3	MD5 hash of namespace + name	No	Deterministic - same input = same UUID	Rarely used
v4	Random (this tool)	No	No information leakage	Most widely used
v5	SHA-1 hash of namespace + name	No	Deterministic - same input = same UUID	Niche use
v7	Unix timestamp (ms) + random	Yes	Leaks creation time (by design)	New standard (RFC 9562, May 2024)

UUID v4 remains the right choice when you need a random, unique identifier with no embedded metadata. If you need time-sortable IDs, consider ULIDs or UUID v7. The key trade-off: v4 is private and unpredictable, v7 is sortable and faster for database inserts.

When Should You Use v7 Instead of v4?

UUID v7 dedicates its first 48 bits to a Unix timestamp in milliseconds, making the IDs chronologically sortable. This matters for database performance. Random v4 UUIDs scatter inserts across a B-tree index, causing page splits - benchmarks show 5,000 to 10,000 page splits per million records with v4, versus just 10 to 20 with sequential IDs. That translates to 2 to 10 times slower INSERT performance on PostgreSQL and MySQL at scale.

PostgreSQL 18 (released 2025) added a native uuidv7() function. Internal benchmarks showed v7 generation was about 33% faster than v4 (58.1 vs 86.8 microseconds per operation), with 16% higher throughput at 34,127 vs 29,238 operations per second. PostgreSQL 18 also guarantees strict monotonic ordering when multiple v7 values are generated within the same millisecond from the same backend, using the 12-bit sub-millisecond precision field rather than pure randomness.

That said, v7 exposes the creation timestamp. For session tokens, authentication keys, or any context where ID predictability is a security concern, stick with v4. UUID v4 values are unpredictable by design, and that randomness is the whole point.

How Unique Are UUID v4 Values?

With 122 random bits, there are 5.3 x 10^36 possible UUID v4 values. Collision probability follows the birthday problem - the chance that any two generated UUIDs match grows quadratically with the number of UUIDs, not linearly. Even so, the numbers are reassuringly tiny.

UUIDs Generated	Collision Probability
1 million	~0.00000000000000000009%
1 billion	~0.00000000000009%
1 trillion	~0.00000009%
800 trillion	1 in 1 billion (0.0000001%)
2.71 x 10^18 (2.71 quintillion)	50%

Generating 1 billion UUIDs per second nonstop, it would take roughly 85 years to reach that 50% collision threshold. For practical purposes, UUID v4 collisions do not happen. The birthday bound for 122-bit identifiers is 2^61, or about 2.3 x 10^18 - you need that many UUIDs before the probability even approaches significant.

Common Use Cases

Use Case	Why UUID	Example
Database primary keys	Generated on any node without coordination	PostgreSQL, MongoDB, DynamoDB
API idempotency keys	Ensures retried requests are not processed twice	Stripe, PayPal payment APIs
Correlation IDs	Traces a request across microservices	Logging, distributed tracing (Jaeger, Zipkin)
Session identifiers	Unpredictable and unique per session	Authentication systems, JWTs
File and object naming	Guarantees no name collisions in shared storage	S3 bucket keys, file uploads
Test data fixtures	Repeatable IDs for seed data	CI/CD test databases

One common mistake: using UUIDs as URL slugs. While it works technically, a 36-character string is hard to read, share, or remember. For user-facing URLs, a shorter identifier (nanoid, base62-encoded ID, or a human-readable slug) is usually a better choice. Keep UUIDs for internal system identifiers.

UUID Storage in Databases

How you store UUIDs affects both disk usage and query speed. A UUID stored as a VARCHAR(36) takes 36 bytes and requires string comparison for lookups. As a BINARY(16), it uses only 16 bytes with native binary comparison - roughly 2.25 times more storage-efficient.

Storage Format	Size	Index Performance	Readability
VARCHAR(36) with hyphens	36 bytes	Slower (string comparison)	Human-readable
CHAR(32) without hyphens	32 bytes	Slightly better	Less readable
BINARY(16)	16 bytes	Best (binary comparison)	Not human-readable
PostgreSQL UUID type	16 bytes	Optimised native type	Displayed as hyphenated string

If your database has a native UUID type (PostgreSQL, CockroachDB, MariaDB 10.7+), use it. Native types store 16 bytes internally but display the standard hyphenated format in queries. For MySQL without native UUID support, BINARY(16) with UUID_TO_BIN() and BIN_TO_UUID() functions is the recommended approach. On high-volume tables with millions of rows, the storage savings and faster binary comparisons add up significantly.

Is a GUID the Same as a UUID?

In practice, yes. GUID (Globally Unique Identifier) is Microsoft's term for the same 128-bit identifier format. The generation algorithm and structure are identical to UUID v4. The main visible difference: Microsoft tools and .NET typically display GUIDs wrapped in curly braces, like {550e8400-e29b-41d4-a716-446655440000}, and often use uppercase hex. This generator includes both options - tick "GUID braces" and "Uppercase" to match the .NET format. SQL Server's NEWID() function produces v4 GUIDs, while NEWSEQUENTIALID() is closer to v7 behaviour with time-ordered values.

Generating UUIDs in Code

Most languages and frameworks include built-in UUID generation. Using the native implementation is always preferable to writing your own, since they handle the cryptographic randomness and bit manipulation correctly.

Language/Platform	Function	Version
JavaScript (browser)	crypto.randomUUID()	v4
Node.js	crypto.randomUUID()	v4
Python	uuid.uuid4()	v4
Java	UUID.randomUUID()	v4
C# / .NET	Guid.NewGuid()	v4
Go	uuid.New() (google/uuid)	v4
Ruby	SecureRandom.uuid	v4
PostgreSQL 18+	uuidv4() / uuidv7()	v4 or v7

In browsers, crypto.randomUUID() (available since 2021 in all major browsers) is the modern standard. This tool uses the same underlying Web Crypto API.

Common Mistakes with UUIDs

UUIDs look simple, but several pitfalls catch developers regularly.

Using Math.random() for generation. Many online snippets generate UUIDs with Math.random(), which is not cryptographically secure. Math.random() uses a PRNG (pseudo-random number generator) that can be predicted if the seed is known. For any UUID that will serve as a security token, session ID, or API key, always use crypto.getRandomValues() or crypto.randomUUID() instead. This tool uses the Web Crypto API, which draws from the operating system's cryptographic entropy pool.

Treating UUIDs as globally sequential. UUID v4 values have no inherent order. Sorting a table by a v4 UUID column will produce random order, not insertion order. If you need to know when a record was created, add a separate created_at timestamp column, or switch to UUID v7 which embeds a timestamp.

String comparison instead of binary. Comparing UUIDs as strings is case-sensitive in most languages. The UUID 550E8400-... and 550e8400-... are the same identifier but will fail a case-sensitive string comparison. Always normalise to lowercase before comparing, or better yet, use your language's native UUID type which handles this internally.

Storing as VARCHAR without indexing strategy. On tables with millions of rows, a VARCHAR(36) UUID primary key with a standard B-tree index will underperform. Random v4 inserts cause page splits at a rate of roughly 5,000 to 10,000 per million rows, compared to 10 to 20 for sequential keys. If you must use v4, consider a secondary auto-increment column for the clustered index and put the UUID on a non-clustered unique index.

Assuming collision detection is unnecessary. While v4 collisions are vanishingly unlikely, production systems should still use a UNIQUE constraint on UUID columns. The cost of the constraint is trivial, and it catches bugs in UUID generation logic (broken RNG, misconfigured library) that are far more likely than a genuine random collision.

For time-ordered identifiers, try the ULID generator which produces 26-character Crockford base32 strings that sort chronologically. For secure random strings of custom length, the password generator offers full control over character sets. To create deterministic hashes from input data, the hash generator supports SHA-256, SHA-512, and other algorithms.

Sources

• IETF RFC 9562 - Universally Unique IDentifiers (UUIDs), May 2024
• The Nile - UUIDv7 Comes to PostgreSQL 18
• Wikipedia - Birthday Attack (collision probability mathematics)
• PostgreSQL 18 Release Notes