UUIDs Explained: Versions 4 and 7 and When to Use Them
What a UUID is, how version 4 and version 7 are built, why collisions are not a worry in practice, and why a UUID must not be used as a secret.
In this article
A UUID is a 128-bit label that can be created anywhere without asking a central server, and still be unique for all practical purposes. They are used as database keys, file names, request IDs and more. This guide explains the format, the difference between version 4 and version 7, and the cases where a UUID is the wrong tool.
What a UUID looks like
A UUID is 16 bytes, written as 32 hex digits in five groups separated by hyphens, in the pattern 8-4-4-4-12. An example is f81d4fae-7dec-11d0-a765-00a0c91e6bf6. The format is defined in RFC 9562, which replaced the older RFC 4122. Two small fields inside identify the layout. The first digit of the third group is the version, and the first digit of the fourth group, which is 8, 9, a or b for standard UUIDs, marks the variant.
Version 4: random
Version 4 is the one most people use. Apart from the 6 bits that fix the version and variant, the other 122 bits are random. A valid version 4 UUID therefore always has a 4 as the first character of the third group, such as 3b241101-e2bb-4255-8caf-4136c566a962. Everything else is chance, so a good source of randomness matters. The standard says to use a cryptographically secure generator, which in a browser is crypto.getRandomValues, the one this site's tool uses.
Version 7: random but sortable
Version 7 puts a 48-bit timestamp, in milliseconds since 1970, at the front, and fills the rest with random bits. Newer UUIDs therefore sort after older ones. This matters for databases. A random version 4 key lands at a random place in an index, which the RFC says gives poor index locality and can significantly hurt database performance, while time-ordered keys stay close together. RFC 9562 prefers version 7 over the older time-based versions 1 and 6 for this reason. The cost is that a version 7 UUID reveals roughly when it was created.
Will two UUIDs ever collide?
With 122 random bits, there are about 5.3 undecillion possibilities, which is 5.3 followed by 36 zeros. After generating a billion version 4 UUIDs, the chance of any pair matching is still far below one in a billion billion. For ordinary applications you can treat them as unique. The standard still tells designers to weigh the cost of a collision: a duplicate log entry is harmless, while a duplicate key in a safety-critical system is not. The weak point is usually a poor random generator, not the maths.
A UUID is not a secret
RFC 9562 is clear that UUIDs must not be used as security capabilities, meaning an ID whose possession grants access. A link such as /invoice/3b241101-e2bb-4255-8caf-4136c566a962 should still check that the visitor is allowed to see the invoice. Version 7 is even less suitable as a secret, because part of it is a timestamp. If you need an unguessable token, such as a password reset link, generate a dedicated random token and store it with an expiry. If a UUID is involved in any security operation, the standard recommends version 4.
When to use which
- Version 4: general purpose IDs, request IDs, file names, anything where order does not matter.
- Version 7: primary keys in a database table that grows large, and logs that should sort by time.
- An ordinary number: when one database hands out the IDs, a counter is smaller, faster and easier to read.
- A random token, not a UUID: for secrets.
Formatting choices
Hyphens and case are only presentation. The same UUID can be written in upper or lower case, with or without hyphens, and systems should compare them without regard to case. RFC 9562 allows upper or lower case hex digits. Some systems store the 16 bytes directly rather than the 36-character text, which saves space.
As an example of how a version 7 UUID is built, the first twelve hex digits are the time. The value 018f1b2c3d4e is a moment in milliseconds, and a UUID made a millisecond later starts with 018f1b2c3d4f. Sorting the text of two such UUIDs as plain strings therefore puts the older one first, with no special code needed. Within the same millisecond the order is decided by the random bits, so strict ordering needs extra care.
Sources
Image credits: Cover photo: Barcode 2409057265.jpg) by allen watkin from London, UK, CC BY-SA 2.0; Picture in the text: Conference pear label - 2025-12-03 - Andy Mabbett by Andy Mabbett, CC BY-SA 4.0. Pictures from Wikimedia Commons.
Share
Keep reading
Related articles
Regular Expressions Basics: Flags, Groups and Pitfalls
A plain guide to regular expressions in JavaScript: the flags, capture groups, named groups, lookahead, and how nested repeats can make a pattern freeze.
URL Encoding Explained: What %20 and %3D Mean
Why URLs need percent-encoding, which characters are safe, how encodeURI and encodeURIComponent differ, and how to fix the most common double-encoding and plus-sign mistakes.
What Is Base64? How to Encode and Decode It
What Base64 is for, how 3 bytes become 4 characters, why the text grows by a third, the URL-safe form and the common mistakes, including thinking it is encryption.