What a UUID is, how the 8-4-4-4-12 format works, UUID v4 vs v7 and the other versions, how unlikely a v4 collision is, and how UUIDs affect database indexes.
By Udit Agarwal · Updated October 17, 2026
A UUID (universally unique identifier) is a 128-bit number used to label something uniquely without asking a central authority for the next available ID. It is usually written as 32 hexadecimal digits in five groups, such as 246845d1-a8e0-4972-999a-e6660394dcda. RFC 9562, published in 2024, defines the format and its versions; the two that matter most today are random version 4 and time-ordered version 7.
A UUID is 16 bytes, or 128 bits. The standard text form writes them as 32 hexadecimal digits in groups of 8, 4, 4, 4 and 12, separated by hyphens, for 36 characters in all. Two digits carry metadata:
246845d1-a8e0-4972-999a-e6660394dcda it is 4.The remaining bits depend on the version: random data, a timestamp, a hash of a name, or a mix. The letters a to f are not case-sensitive, and RFC 9562 asks for lowercase output; Microsoft tools often show uppercase in braces, like {246845D1-A8E0-4972-999A-E6660394DCDA}. Two special values exist: the nil UUID, all zeros, which stands for "no value", and the max UUID, all f's.
| Version | How it is made | Typical use |
|---|---|---|
| v1 | 60-bit timestamp in 100-nanosecond steps since 15 October 1582, plus a node ID, usually the MAC address | older systems; MySQL's UUID() |
| v3 | MD5 hash of a namespace and a name | deterministic IDs (v5 is preferred) |
| v4 | 122 random bits | general-purpose IDs |
| v5 | SHA-1 hash of a namespace and a name | the same input always gives the same UUID |
| v6 | v1 with the timestamp reordered so it sorts | upgrading v1 systems |
| v7 | 48-bit Unix timestamp in milliseconds, then random bits | database keys that sort by creation time |
| v8 | layout chosen by the implementer | custom or experimental schemes |
Version 2, reserved for DCE security, is almost never seen. Version 1 reveals when an ID was made and, usually, which machine made it, one reason most new systems use v4 or v7 instead.
Name-based UUIDs are deterministic. Version 5 hashes a namespace UUID together with a name using SHA-1 and keeps 122 of the hash's bits. The DNS namespace with the name www.example.com always gives 2ed6657d-e927-568b-95e1-2665a8aea6a2, in any language. That makes v5 useful for deriving a stable ID from something that already identifies a record, such as a URL. The Hash Generator computes SHA-1 digests, and the hashing guide explains what a digest is.
A version 4 UUID has 122 random bits, because 6 of the 128 bits are fixed by the version and variant. That allows 2¹²², about 5.3 × 10³⁶, different values. The chance that any two of n random UUIDs match follows the birthday problem, and for numbers this size it is approximately n² ÷ (2 × 2¹²²):
| UUIDs generated | Chance of any duplicate |
|---|---|
| 1 million | about 1 in 10²⁵ |
| 1 billion | about 1 in 10¹⁹ |
| 103 trillion | about 1 in a billion |
| 2.7 × 10¹⁸ | about 50% |
Even odds take about 2.7 quintillion UUIDs, which at a billion per second would take 86 years to generate. In practice, duplicates come from broken random number generators, such as virtual machines cloned with the same random state or code that uses a weak generator, not from bad luck. Use the platform's cryptographic generator: crypto.randomUUID() in browsers and Node.js, or uuid.uuid4() in Python.
Version 7 puts the time first. Its first 48 bits are a Unix timestamp in milliseconds, followed by the version digit, then 74 bits that are random or partly a counter, with the variant inside them. Because the timestamp leads, v7 values sort by creation time, both as text and as bytes.
Take 01a149bb-b200-7000-bcf5-13d311b3024f. Its first 12 digits, 01a149bbb200, are 1792238400000 in decimal, which is 12:00:00 UTC on 17 October 2026 in milliseconds. You can decode one yourself with the Number Base Converter and the Unix Timestamp Converter.
| UUID v4 | UUID v7 | |
|---|---|---|
| Contents | 122 random bits | 48-bit timestamp, 74 random or counter bits |
| Order | none | sorted by creation time |
| Reveals | nothing | when it was created |
| Index inserts | scattered across the index | added near the end |
As a rule of thumb, use v7 for database primary keys and anything you sort or query by time. Use v4 when the ID is public and its creation time should stay private. Neither is a secret: RFC 9562 warns against assuming UUIDs are hard to guess, so do not use one as a password or a private link.
An auto-increment column hands out 1, 2, 3 and so on. It is compact (4 or 8 bytes), ordered and easy to read, but UUIDs avoid its drawbacks:
uuid type or BINARY(16) in MySQL.Auto-increment still suits small internal tables and numbers people read aloud, such as order numbers. Many systems use both: an integer key inside the database and a UUID in URLs and APIs.
Most databases keep primary keys in a B-tree index, and some, like MySQL's InnoDB engine, store the table itself in primary-key order. Sequential keys always land at the right-hand end of the tree, so new rows fill the last page and the pages being written stay in memory.
Random v4 keys land anywhere. Each insert touches a different page. Once the index is larger than memory, inserts wait on disk reads, and pages split and are left partly empty, so the index grows larger than it needs to be. Version 7 keys arrive in roughly increasing order, so they behave much like an auto-increment column while keeping the benefits of UUIDs. RFC 9562 lists this poor index locality among its reasons for adding the time-ordered versions. Support is spreading: PostgreSQL 18 added a built-in uuidv7() function, and Python 3.14 added uuid.uuid7().
GUID, for globally unique identifier, is Microsoft's name for a UUID. .NET's Guid.NewGuid() and SQL Server's NEWID() produce random version 4 values in the same 8-4-4-4-12 format. The one practical difference is byte order: when Windows and .NET convert a GUID to raw bytes, they store the first three groups in little-endian order, so the same identifier can produce a different byte sequence than other systems would. The text form is identical, which makes it the safest way to exchange them.
The UUID Generator makes version 4, version 7 or nil UUIDs, from 1 to 1,000 at a time. Version 4 values come from the browser's built-in crypto.randomUUID(). Version 7 values follow the RFC 9562 layout: the current time in milliseconds, then a 12-bit counter that keeps a batch in the order it was generated even within one millisecond, then random bits from the Web Crypto API. You can switch to uppercase, copy the whole list or download it as a .txt file. Everything is generated in your browser and nothing is uploaded.
It does not make v1, v3, v5, v6 or v8 UUIDs, and it does not parse or validate existing ones. For other ID formats, the ULID Generator makes sortable 26-character IDs and converts them to and from UUIDs, and the Nano ID Generator makes shorter URL-safe IDs with a custom length and alphabet.
What is a UUID used for? A UUID labels a record, file, message or device with an ID that will not clash with IDs made elsewhere. Because no central counter is needed, separate servers, apps and offline devices can all create IDs and merge them later.
Can two UUIDs ever be the same? In theory yes, in practice not with a proper random source. Even after a billion random version 4 UUIDs, the chance of any duplicate is about 1 in 10¹⁹. Real duplicates come from faulty random number generators or copied state, not chance.
What is the difference between UUID v4 and v7? Version 4 is 122 random bits with no order. Version 7 starts with a millisecond Unix timestamp, so values sort by creation time and keep database indexes compact, at the cost of revealing when each ID was made.
Is a GUID the same as a UUID? Yes. GUID is Microsoft's name for a UUID, and the text format is identical. The only difference shows up when the value is converted to raw bytes, where Microsoft stores the first three groups in a different byte order.
Should I use UUIDs as database primary keys? They work well when IDs are created in many places or shown publicly. Prefer version 7 to version 4 for keys, store them in a native 16-byte type rather than as text, and keep an auto-increment integer if the table is small and internal.
Are UUIDs case-sensitive? No. The hexadecimal letters a to f mean the same in either case, and RFC 9562 says they are read in any case and written in lowercase. If your data mixes both, normalize the case before comparing.
How do I get the time out of a UUID v7? Take the first 12 hexadecimal digits, ignoring the hyphen, and convert them to decimal. The result is a Unix timestamp in milliseconds, which any timestamp converter turns into a date.
All Date / Time tools · All guides