UUID v4 or v7: which one to use, and why it matters

Use UUID v4 when you need a random identifier and nothing more. Use UUID v7 when the identifier will be a database key, or when you want IDs to sort by creation time. Both are 128 bits written in the same 36-character form, so the difference lies in how the bits are arranged. The tool below generates either version, one to 500 at a time, in your browser.

UUID generatorNeed unique IDs for my codeOpen

What a UUID looks like

A UUID, or universally unique identifier, is a 128-bit number written as 32 hexadecimal digits in five groups: 8, 4, 4, 4 and 12 digits, separated by hyphens. An example is 3f2b8c1e-6d4a-4f7b-9c2e-8a1d5e0b7f63.

Two parts of the number are fixed. Four bits hold the version, so the third group starts with 4 for v4 or 7 for v7. Two bits hold the variant, so the fourth group starts with 8, 9, a or b. The rest carries the identifier itself. The variant and version bits are why a v4 UUID has 122 random bits, not 128.

UUID v4: random

A v4 UUID is random apart from those fixed bits. Its 122 random bits make a repeat extremely unlikely. Suppose you generate a billion v4 UUIDs. The chance that any two match is roughly n squared divided by twice the number of possible values, which comes to about 10 to the power of minus 19. In other words, collisions are not something you need to design around.

That estimate assumes the generator draws its bits from a cryptographic random source. A predictable generator would undermine that estimate. This tool uses the browser's cryptographic random source, through crypto.randomUUID or crypto.getRandomValues.

UUID v7: time first

RFC 9562 defines v7. Its first 48 bits hold the Unix time in milliseconds, so an ID made later has a larger first part than an ID made earlier. After that come the version bits, then random bits, the variant bits and more random bits. Some of the random space can hold a counter, which keeps IDs in order when several are made within the same millisecond.

Because the time comes first, sorting v7 IDs as text, in one consistent case, sorts them by creation time, to the millisecond. That works because the hexadecimal digits are fixed width and the time is in the leading characters.

The time is also visible. Anyone who reads a v7 UUID can see roughly when it was made. You can check this yourself with the Inspect field, which turns the first 48 bits back into a date and time.

Why v7 suits database indexes

A database index is usually a B-tree, a structure kept in sorted order by key. When the key is random, as with v4, each new row lands in a random place in the index. The database then has to write into many different parts of the index, which causes more page splits and more cache misses. Over a large table, that work adds up.

A v7 key is larger than almost every key already in the index, because its time part grows. New rows are added near the end of the index, much as an auto-incrementing number would be. Recent index pages stay in memory, and writes stay tidy. The difference is most noticeable in large tables that grow all the time, and it is hard to see in a small one.

Choosing between v4 and v7

Database primary keys, or any table that grows over time: v7. The index stays orderly.
Logs, events or messages you often sort by time: v7, because the ID itself carries the order.
Public IDs where the creation time should stay private: v4. A v7 ID reveals when it was made.
Many devices with unreliable clocks: v4 or v7 both stay unique, because the random bits do that work. Only the sort order of v7 depends on the clocks being right.

Both versions are standard, but older libraries may only know v4. RFC 4122 described versions 1 to 5 for many years. RFC 9562 was published in May 2024, replaces RFC 4122, and defines versions 6, 7 and 8. Check that your library's version supports v7 before you rely on it.

Storing UUIDs

A UUID written as text takes 36 characters. Its 16 bytes can be stored in binary form, which takes far less space. Many databases have a native UUID type or a 16-byte binary column for this purpose, and it compares faster than text.

Pick one format and keep it. Uppercase, lowercase, hyphens and braces are all the same UUID to a person, but a database or a string comparison may treat them as different values. The generator's uppercase, no hyphens and braces options exist for systems that need those forms.

Never use a UUID as a secret

A UUID is an identifier, not a password, a session token or an access key. It is built to be unique, not to be unguessable. A v7 UUID also carries its creation time. And identifiers get pasted into links, logs, emails and screenshots, where anyone who sees them can reuse them.

Access control belongs on the server. A person who knows an ID should not automatically be allowed to see or change the record it names. For passwords, passphrases or tokens, use a generator built for secrets. The password generator makes random passwords or word passphrases on your device with secure randomness, and it estimates their strength. For background on why length and randomness matter, read strong passwords and entropy.

Using the tool

Choose version 4 for random IDs, or version 7 for IDs that sort by time.
Set the count, from 1 to 500 at a time.
Tick uppercase, no hyphens or braces if your code needs a particular form.
Copy all of them, or download the list as a .txt file.
Paste any UUID under Inspect to read its version, its variant and, for v7, the time embedded in it.

Quick answers

Is a v4 UUID unique? In practice, yes. Its 122 random bits make a repeat so unlikely that you do not need to check for one.

Should I use v7 for everything? Not always. Use v7 for database keys and anything sorted by time. Use v4 when the creation time should stay hidden.

Can I use a UUID as a password? No. It is an identifier. Use a password generator for anything that must stay secret.

Does the tool send the IDs anywhere? No. The IDs are made and shown in your browser, and they are not sent to a server.