UUID v4 vs v7: what they are and when to use each

A UUID is a 128-bit identifier you can generate anywhere without asking anyone, with a negligible chance of ever repeating. That is why it is the default key for distributed systems. How one is built, when to use version 4 and when version 7, and the one thing a UUID is not: a secret.

Reviewed on 3 October 2026 · 4 min read

What a UUID looks like

A UUID (Universally Unique Identifier) is a 128-bit value, written as 32 hexadecimal digits in five groups separated by hyphens: cf217f18-8cc6-4677-aa1e-5b7bc89ae6eb, 36 characters in all. Two small fields inside it say what kind it is: a version (the first digit of the third group; here it is 4) and a variant (the first digit of the fourth group). The standard that defines them is RFC 9562, published in 2024, which obsoletes the older RFC 4122.

Version 4: random

UUIDv4 is meant for generating UUIDs from truly random or pseudorandom numbers. Of the 128 bits, 6 are fixed by the version and variant, which leaves 122 random bits. It is the version most people mean by "a UUID": no timestamp, no machine information, just randomness. You can make one in your browser with the UUID generator, which produces as many as you need and works locally.

Version 7: time-ordered

UUIDv7, new in RFC 9562, puts a Unix timestamp in milliseconds (the number of milliseconds since midnight on 1 January 1970 UTC, leap seconds excluded) in the most significant 48 bits and fills the rest with random bits. Because the timestamp comes first, UUIDs created later sort after earlier ones.

That matters for databases. RFC 9562 explains that UUID versions which are not time-ordered, such as v4, have poor database-index locality: new values created in succession are not close to each other in the index, so inserts happen at random locations, with the performance cost that brings on the usual index structures. A v7 key is appended near the end of the index instead. If a UUID is going to be a primary key on a large table, v7 is normally the better choice; if the ID is never used for ordering or as a key, v4 is fine.

FeatureUUIDv4UUIDv7
Contents122 random bits48-bit millisecond timestamp, then random bits
Sorts by creation timeNoYes (to the millisecond)
Database index localityPoorGood
Reveals creation timeNoYes, to anyone who reads it
Best forOpaque IDs, tokens' identifiers, anything that should not reveal orderPrimary keys, logs, anything you want to sort

The timestamp in a v7 cuts both ways: it gives you ordering, but also shows when the record was created. RFC 9562 notes that the embedded timestamp poses a very small attack surface, since it signals the order of creation. If creation time is sensitive, prefer v4.

How likely is a collision?

With 122 random bits there are about 5.3 × 1036 possible v4 values. The chance that two of n random UUIDs collide is roughly n² ÷ (2 × 5.3 × 1036). Putting numbers on it:

  • One billion UUIDs: a probability of around 10-19, about one in ten quintillion.
  • One trillion UUIDs: around 10-13.
  • To reach even a one-in-a-billion chance of a single duplicate you would need to generate about 103 trillion of them.
  • A 50% chance needs roughly 2.7 quintillion (2.7 × 1018).

For any real application the probability that two honest v4 UUIDs collide is far below the probability of a hardware fault. The caveat is "honest": this assumes a good source of randomness. RFC 9562 warns that discovering predictability in a random number source results in a vulnerability, which is why UUIDs should come from a cryptographically secure generator, not from something like Math.random().

What a UUID is not

This is the part people get wrong. A UUID is an identifier, not a secret. RFC 9562 says implementations should not assume UUIDs are hard to guess and that they must not be used as security capabilities, meaning identifiers whose mere possession grants access. So do not use a UUID as a password-reset link, an API key, a share link that must stay private or a session token. For those, use a long random value from a secure generator (see how to create strong passwords for what "long enough" means) and treat it as a secret. A UUID in a URL is fine as an ID; "anyone with this URL can see it" is a different design decision, and a UUID alone does not make it safe.

Also avoid the older time-and-MAC-address versions for new work: RFC 9562 says MAC addresses pose inherent privacy risks and should not be used in a UUID.

Practical tips

  • Store them compactly. A UUID is 16 bytes; many databases have a native UUID type that is smaller and faster than a 36-character string.
  • Compare in one format. The text form is case-insensitive per the standard, but mixing upper and lower case in comparisons causes bugs; normalise to lowercase.
  • Do not parse meaning out of them unless you know the version. Only v1, v6 and v7 carry a timestamp.
  • Do not shorten them. Cutting a UUID to its first 8 characters destroys the uniqueness guarantee.

Sources and further reading

Figures checked on 3 October 2026.

Do it now, free, in your browser. Your files are not uploaded.

Generate UUIDs (v4 and v7) in bulk, in the format you need.

UUID generatorHash generator

Frequently asked questions

What is a UUID?
A 128-bit identifier, written as 32 hexadecimal digits in groups of 8-4-4-4-12, that can be generated anywhere without coordination and is extremely unlikely to repeat.
What is the difference between UUID v4 and v7?
v4 is 122 random bits with no ordering. v7 starts with a 48-bit millisecond Unix timestamp, so values sort by creation time and index much better in a database, but they reveal when they were created.
Can two UUIDs be the same?
In theory yes, in practice no: you would need to generate about 103 trillion v4 UUIDs for a one-in-a-billion chance of a single duplicate, assuming a good random source.
Is a UUID secret or hard to guess?
No. RFC 9562 says not to assume UUIDs are hard to guess and not to use them as security capabilities. Use a long random token from a secure generator for secrets.
Should I use a UUID as a database primary key?
It is common in distributed systems. Prefer v7 for large tables because its time ordering gives better index locality than random v4.
Is it safe to generate UUIDs in the browser?
Yes, if the generator uses a cryptographically secure random source. UtilsDock's UUID generator runs locally in your browser and sends nothing anywhere.

Related guides

Data and developersChecksums and hashes: how to verify a download with SHA-256What a hash is, how to check a file's SHA-256 against the published one, why MD5 and SHA-1 are retired for security, and why SHA-256 is wrong for passwords.4 min read Data and developersUnix timestamps explained: seconds, milliseconds and the year 2038What a Unix timestamp is, how to tell seconds from milliseconds, why a 10-digit number gives a date in 1970, and what the 2038 problem really is.4 min read Data and developersWhat is Base64? Encoding, not encryptionBase64 encrypts nothing: what it does, why the output is a third bigger, what the = padding and the URL-safe variant are, and why btoa() breaks on accents.4 min read

Tools used in this guide

They run in your browser, so nothing is uploaded.

UUID generatorGenerate UUIDs (v4 and v7) in bulk, in the format you need. Hash generatorCalculate MD5 and SHA hashes of text or files, and verify a checksum. Random string generatorGenerate random strings, tokens and codes with the characters and length you choose. JSON formatter and validatorFormat, validate and repair JSON, with the exact line of any error. AI API cost calculatorEstimate the cost of an AI API from token prices and your usage, and compare two models. Base64 encode and decodeConvert text, files and images to and from Base64, in your browser.