UUIDs, Explained: v4, v7 and GUIDs

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.

What is a UUID?

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:

  • The first digit of the third group is the version. In 246845d1-a8e0-4972-999a-e6660394dcda it is 4.
  • The first digit of the fourth group is the variant, which is 8, 9, a or b for standard UUIDs. Here it is 9.

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.

UUID versions

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.

How likely is a UUID v4 collision?

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.

UUID v4 vs v7

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.

UUIDs vs auto-increment IDs

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:

  • Coordination. Only the database can issue the next number, so a client cannot know an ID before the insert, and merging databases or shards means renumbering. UUIDs can be created anywhere, even offline, without conflicts.
  • Exposure. Sequential IDs leak information. A URL ending in /invoices/1043 suggests that invoice 1042 exists and hints at how many you have issued.
  • Size. The trade-off: a UUID takes 16 bytes as binary and 36 characters as text. Store it as 16 bytes where you can, such as PostgreSQL's 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.

UUIDs and database index performance

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().

UUID vs GUID

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.

Generate UUIDs with ArrayKit

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.

Frequently asked questions

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.

Keep going

UUID Generator

More guides

  • Date Calculations, Explained: Counting and Adding Days — How to count the days between two dates, add days, weeks or months to a date, and why calculators disagree: inclusive counts, month ends and leap years.
  • How Exact Age Is Calculated — How to calculate exact age in years, months and days: the borrow method, 29 February birthdays, total days and weeks, and why calculators differ by a day.
  • Cron Expressions, Explained — Crontab syntax explained: the five cron fields, special characters, common schedules, the day-of-month or day-of-week rule, @daily shortcuts and time zones.
  • Unix Timestamps and Epoch Time, Explained — What a Unix timestamp is, why epoch time ignores leap seconds, how to tell seconds from milliseconds, converting in JS, Python and SQL, and the 2038 problem.
  • Time Zones, UTC and Daylight Saving, Explained — UTC vs GMT, offsets such as +05:30 and +05:45, IANA zone names, why EST and IST are ambiguous, daylight saving shifts, and using a time zone converter well.
  • The Pomodoro Technique, Explained — How the Pomodoro Technique works: the 25-minute focus session, the 5-minute break, the long break after four, popular variations like 50/10, and tips that help.

All Date / Time tools · All guides