What Is a UUID v4? Format, Uniqueness and When to Use v7

The short answer

A UUID (Universally Unique Identifier) is a 128-bit ID written as 32 hexadecimal digits in five groups, like f47ac10b-58cc-4372-a567-0e02b2c3d479. A version 4 UUID is made almost entirely of random bits (122 of the 128), so anyone can generate one without a central server and still be confident it will not clash with anyone else's.

The UUID Generator creates 1 to 1,000 version 4 UUIDs at once using your browser's cryptographic random number generator.

The format, piece by piece

A UUID in its standard text form is 36 characters: 32 hex digits plus 4 hyphens, grouped 8-4-4-4-12.

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

• M is the version digit. For a version 4 UUID it is always 4.
• N is the variant. For standard UUIDs its first two bits are 10, so this digit is always 8, 9, a or b.
• Every other digit is random.

So you can recognise a v4 UUID at a glance: the 13th digit is 4 and the 17th digit is 8, 9, a or b. In f47ac10b-58cc-4372-a567-0e02b2c3d479, the third group starts with 4 and the fourth group starts with a.

UUIDs are defined in RFC 9562, published by the IETF in May 2024. It replaced the older RFC 4122 and added new versions, including v7. "GUID" is Microsoft's name for the same thing; a GUID generated by modern Windows tools is a UUID.

How unique is "unique"?

A version 4 UUID has 122 random bits, which gives 2¹²² (about 5.3 × 10³⁶) possible values. Collisions are not impossible, but the chance is extremely small when the random source is good. Using the standard birthday-problem approximation:

UUIDs generated	Chance at least two are identical
1 million	about 1 in 10²⁵
1 billion	about 1 in 10¹⁹
103 trillion	about 1 in a billion
2.7 × 10¹⁸	about 50%

You would need to generate around 2.7 quintillion v4 UUIDs before a duplicate becomes a coin flip. In practice, collisions come from bad random number generators (for example a non-cryptographic generator seeded with the time), not from the maths.

The Lazyblink generator uses crypto.getRandomValues(), the browser's cryptographically secure source, then sets the version and variant bits as the standard requires.

Using the UUID Generator

Open the UUID Generator.

Enter a Quantity from 1 to 1,000.

Choose a Format (options below).

Click Generate.

Hover over a row and click Copy for one UUID, click Copy all for the whole list (one per line), or Download .txt to save them.

The three formats:

• Standard (v4): lowercase with hyphens, e.g. 3f2b8c1e-9d4a-4e7b-b5c2-6a1f0e9d8c7b.
• UPPERCASE: the same value in capital letters. Some Microsoft tools display GUIDs this way.
• No hyphens: 32 hex characters, handy for file names or systems with length limits.

All three formats are the same underlying value. Uppercase and lowercase UUIDs are equal by the standard, and the hyphens are only for readability, so a system can store one form and display another.

UUID v4 vs UUID v7

RFC 9562 introduced version 7, which puts a 48-bit Unix timestamp in milliseconds at the front, followed by random bits. The RFC says implementations should use v7 instead of the older time-based v1 and v6 where possible.

| UUID v4	UUID v7
Contents	122 random bits	48-bit millisecond timestamp + random bits
Sort order	Random	Roughly by creation time
Reveals creation time	No	Yes, to the millisecond
Database index behaviour	Inserts land all over the index	New rows go near the end of the index
Best for	Tokens, public IDs, anything where order or timing should not leak	Primary keys in large tables, event logs

Why v7 matters for databases: when a v4 UUID is a primary key in a B-tree index, each new row lands at a random spot. On very large tables this can cause more page splits and less efficient caching than sequential keys. Because v7 values increase over time, new rows are added near the end, much like an auto-increment number.

Why you might still want v4: a v7 UUID tells anyone who sees it when the record was created. For public-facing IDs where that is sensitive, v4 is safer. This generator produces v4 only. To generate v7, use your language's library: many current UUID libraries now support it.

When to use a UUID (and when not to)

Good uses:

• IDs created in several places at once (mobile apps offline, microservices) that must not clash when merged.
• IDs exposed in URLs, where a sequential number would reveal how many records you have.
• Idempotency keys for API requests, so a retried payment request is not processed twice.
• Test data and fixtures.

Think twice when:

• You need a secret. A UUID is an identifier, not a password or API key. Even though v4 is random, RFC 9562 notes that UUIDs should not be assumed to be hard to guess for security purposes. Use a purpose-built token, or the Password Generator for human-used secrets.
• Storage is tight. A UUID stored as text takes 36 bytes, compared with 16 bytes in a native binary/UUID column type and 8 bytes for a big integer.
• Humans must read it aloud. Short codes are friendlier for order numbers on phone calls.

Common mistakes

• Storing UUIDs as VARCHAR(36) when the database has a native UUID type. Use the native type where available.
• Comparing UUIDs as case-sensitive strings. Normalise to lowercase first.
• Generating "UUIDs" with Math.random(). It is not cryptographically secure; use crypto.randomUUID() or crypto.getRandomValues() in JavaScript.
• Assuming a UUID hides data. It identifies a record; access control still has to be checked on the server.

Related tools: Hash Generator for checksums and Unix Timestamp Converter if you need to read the time inside a v7 UUID.