UUID vs GUID Explained: Versions 1, 4, and 7 (and Which One to Use)

A UUID and a GUID are the same thing: a 128-bit identifier, written as 32 hexadecimal digits, that two computers can generate independently without ever colliding. UUID (Universally Unique Identifier) is the IETF's name; GUID (Globally Unique Identifier) is Microsoft's name for the identical value. There is no difference in the bits. This article walks the RFC 9562 bit layout ^[rfc9562] and compares the three versions you actually meet in code: 1, 4, and 7.

Microsoft coined GUID for COM and carried it into .NET; the IETF standardized the same structure as UUID. Where the two names diverge is never in the value, only in *text formatting* and occasionally *byte order* inside specific Microsoft tooling, which the final section covers.

What is a GUID, and how does it relate to a UUID?

A GUID is Microsoft's term for a 128-bit identifier used to label objects, COM interfaces, classes, and database rows without a central authority issuing numbers. It is bit-for-bit the same structure the IETF calls a UUID. The format traces back to the 1980s Apollo Network Computing System, which Microsoft adopted ^{[wikipedia-uuid]}. Both names describe a value like `f47ac10b-58cc-4372-a567-0e02b2c3d479`.

A UUID is 128 bits, normally written as 32 hex digits in five hyphen-separated groups (8-4-4-4-12). Two fields are reserved and not free for data: the version (4 bits) names the generation algorithm, and the variant (2 to 3 bits) names the layout rules. Almost all code uses the IETF variant, where the variant bits read `10x`.

What is RFC 9562, the current UUID specification?

RFC 9562 is the IETF UUID specification published in May 2024. It obsoletes RFC 4122 from 2005 ^{[rfc9562][rfc4122]} and does three things: it tightens the language around existing versions 1 through 5, it formally adds versions 6, 7, and 8, and it gives implementers explicit rules on randomness, monotonicity, and time-bit ordering so identifiers can sort by creation time.

Versions 6, 7, and 8 exist to fix two problems with the original version 1. Version 1 was reliable for uniqueness but sorted in a confusing byte order and embedded the generating machine's network MAC address, which leaked hardware identity. The newer versions keep time-ordering and drop the leak.

This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time.

How do UUID versions 1, 4, and 7 compare?

Versions 1, 4, and 7 cover almost everything you meet in practice. Version 1 is the classic timestamp-plus-MAC design. Version 4 is 122 random bits and the default in most languages. Version 7 puts a 48-bit Unix millisecond timestamp in front of 74 random bits, making it sortable by creation time. The table below shows where they differ on the properties that decide a design.

Three things on that table earn a closer look. Version 1 exposes both the generating machine's MAC address and a timestamp, which is why RFC 9562 steers new work toward versions 4, 6, and 7 ^[rfc9562]. Version 4 spends 122 of its 128 bits on randomness, telling an observer nothing about when or where it was made. Version 7 trades some opacity for order: anyone holding a v7 value can read its creation time to the millisecond.

Why is version 4 the safe default?

Version 4 is the safe default because it needs no clock, no coordination between machines, and no MAC address, and it leaks nothing about its origin. With 122 random bits, you would need to generate roughly a billion UUIDs per second for about 85 years to reach a 50 percent chance of one collision ^{[wikipedia-uuid]}. That opacity matters when an identifier shows up in a URL, an email, or a log a third party can read.

One caveat: a v4 UUID is only as unique as the random number generator behind it. Draw those 122 bits from a cryptographically secure source rather than a basic pseudo-random function, or the uniqueness guarantee weakens ^[nist-rng].

Why is version 7 rising for database primary keys?

Version 7 is rising for database primary keys because it fixes index locality. A B-tree index keeps rows sorted, so a random v4 key lands each insert in an unpredictable spot, touching cold pages across disk and cache and splitting index pages repeatedly. A v7 key carries a 48-bit Unix millisecond timestamp in its first bits, so new rows sort near each other and append near the tail of the index, keeping recent pages hot.

The payoff is largest when the storage engine *clusters* table data by primary key. In MySQL InnoDB, the clustered index physically orders rows by primary key, so a random v4 key inserts rows in random physical positions, fragmenting the table ^{[innodb-index]}. A time-ordered v7 key avoids that. PostgreSQL keeps the primary key in a separate B-tree instead of clustering the heap, so the gain is smaller there but still real for index size and cache behavior.

The cost of v7 is privacy. Because it encodes the creation timestamp, publishing a v7 value lets anyone read when a record was made and estimate creation rates by comparing two values. If a record's age is sensitive, keep v7 internal and hand the outside world a separate v4 or an opaque slug.

How do you read the parts of a v7 UUID?

Take the v7 value `018f9d4e-7b2a-7c3d-9e1f-a2b3c4d5e6f7`. Its first 48 bits in hex are `018f9d4e7b2a`, which is 1,716,331,117,354 milliseconds in decimal and decodes to a moment in late May 2024. The `7` in the third group is the version nibble, and the `9` starting the fourth group confirms the IETF variant. In a v4 value, those same positions are pure randomness and decode to nothing.

What GUID-specific quirks should I know about?

The two GUID quirks that trip people up are braces and byte order, and neither changes the underlying value. The Windows registry and some COM APIs wrap GUIDs in braces, like `{f47ac10b-58cc-4372-a567-0e02b2c3d479}`. Separately, when a GUID is stored as a binary blob, certain Microsoft components write the first three groups in little-endian byte order while the last two stay big-endian.

That little-endian mix bites when you treat a stored GUID as a flat 16-byte array: a round trip through such a system can reorder bytes and break an equality check. Before you compare a database GUID against a string, normalize both the text formatting and the byte order.

What does our generator produce, and how should you use it?

The dedicated UUID generator emits version-4 GUIDs: 122 random bits, no embedded timestamp, no machine identity, generated locally. That fits the only purposes we support, which are software testing, QA fixtures, form-filling, seeding development databases, and protecting your privacy when a site demands an identifier it has no real need for. Every value is fictional.

Need v7 keys for production? Generate them inside your application framework or database. Modern PostgreSQL, IBM Db2, and many drivers ship built-in UUID functions ^[ibm-uuid]. Use our v4 output for test data and disposable identifiers, and reach for /tools/password-generator when you actually need a secret instead of an identifier.

Which UUID version should I choose? A quick decision guide

• Need a general-purpose unique ID and want to leak nothing? Use version 4. It is the default for good reasons.
• Building a database primary key on a clustering engine like InnoDB? Use version 7 for index locality, but keep it internal if creation time is sensitive.
• Maintaining a legacy system that already uses version 1? Leave it in place, but avoid v1 for new work because it exposes the MAC address.
• Need a secret, token, or password? A UUID is the wrong tool; use /tools/password-generator.
• Generating test data? Our generator at / produces fictional version-4 GUIDs for exactly this.