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 create independently without colliding. UUID, Universally Unique Identifier, is the IETF's name. GUID, Globally Unique Identifier, is Microsoft's name for the identical value. The bits do not differ. This article walks through the RFC 9562 layout ^[rfc9562] and compares the three versions you 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. The two names never differ in the value. They differ only in *text formatting*, and sometimes in *byte order* inside certain Microsoft tools, as the last 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 that labels objects, COM interfaces, classes and database rows without a central authority issuing numbers. It is the same structure, bit for bit, that the IETF calls a UUID. The format goes back to Apollo's Network Computing System from 1987, which Microsoft adopted ^{[wikipedia-uuid]}. Both names describe a value like f47ac10b-58cc-4372-a567-0e02b2c3d479.

A UUID is 128 bits, usually written as 32 hex digits in five groups separated by hyphens (8-4-4-4-12). Two fields are reserved. The version, 4 bits, names the generation method. The variant, 2 to 3 bits, names the layout rules. Almost all code uses the IETF variant, whose bits read 10x.

What is RFC 9562, the current UUID specification?

RFC 9562 is the IETF's UUID specification, published in May 2024. It replaces RFC 4122 from 2005 ^{[rfc9562][rfc4122]} and does three things. It tightens the wording for versions 1 to 5. It adds versions 6, 7 and 8. And it gives explicit rules on randomness and time ordering, so identifiers can sort by creation time.

Versions 6 and 7 fix two problems with the original version 1. Version 1 was reliable for uniqueness, but it sorted in a confusing byte order. It also embedded the machine's network MAC address, which leaked hardware identity. The newer versions keep the time order and drop the leak. Version 8 is a free-form slot for custom layouts.

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 millisecond timestamp in front of 74 random bits, so it sorts by creation time. The table shows where they differ on the properties that decide a design.

Three rows deserve a closer look. Version 1 exposes the machine's MAC address and a timestamp. RFC 9562 says implementations should use version 7 instead of versions 1 and 6 where possible ^[rfc9562]. Version 4 spends 122 of its 128 bits on randomness, so it tells an observer nothing about when or where it was made. Version 7 trades some privacy 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 and no MAC address, and it reveals nothing about its origin. With 122 random bits, the birthday bound puts an even chance of one collision at about 2.7 quintillion values: a billion per second for about 86 years. That privacy matters when an identifier appears 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, not a basic pseudo-random function, or the guarantee weakens ^[nist-rng]. In JavaScript that means crypto.randomUUID().

Why is version 7 rising for database primary keys?

Version 7 is rising for primary keys because it keeps inserts together. A B-tree index keeps rows sorted. A random v4 key lands each insert in an unpredictable place, touching cold pages and splitting index pages again and again. A v7 key starts with a 48-bit millisecond timestamp. New rows sort near each other at the end of the index, so recent pages stay in cache.

The payoff is largest when the storage engine *clusters* table data by primary key. In MySQL InnoDB, the clustered index stores rows in primary-key order. A random v4 key inserts rows in random positions and fragments the table ^{[innodb-index]}. A time-ordered v7 key avoids that. PostgreSQL keeps the primary key in a separate index instead of ordering the table itself. The gain is smaller there, but still real for index size and caching.

The cost of v7 is privacy. It encodes the creation time, so publishing a v7 value lets anyone read when a record was made. Comparing two values even reveals how fast records are created. If a record's age is sensitive, keep v7 internal and show 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. That is 1,716,331,117,354 milliseconds, which decodes to 21 May 2024 at 22:38 UTC. The 7 that starts the third group is the version, and the 9 that starts the fourth confirms the IETF variant. In a v4 value, those first 48 bits are random 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. Neither changes the underlying value. The Windows registry and some COM APIs wrap GUIDs in braces, like {f47ac10b-58cc-4372-a567-0e02b2c3d479}. And when a GUID is stored as binary, some Microsoft components write the first three groups in little-endian byte order and the last two in big-endian.

That 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 comparing a database GUID with a string, normalize both the text format and the byte order.

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

Our UUID generator emits well-formed version-4 values, with no timestamp and no machine identity. Be clear about what it is. It runs on the site's seeded test-data engine, and each seed is reduced to a 32-bit number. So its values do not carry 122 bits of independent randomness, and they can repeat. That suits the purposes we support: software testing, QA fixtures, form-filling and seeding development databases. Do not use it for production identifiers.

For production keys, generate UUIDs inside your application or database. PostgreSQL ships gen_random_uuid() for version 4 and, since version 18, uuidv7() ^[pg-uuid]. Most languages have a secure built-in, such as crypto.randomUUID() in JavaScript. Use our output for test data, and reach for the password generator when you need a secret instead of an identifier.

Which UUID version should I choose? A quick decision guide

• Need a general-purpose unique ID that reveals nothing? Use version 4, from a secure random source. It is the default for good reasons.
• Building a primary key on an engine that orders rows by key, like InnoDB? Use version 7, but keep it internal if creation time is sensitive.
• Maintaining a legacy system on version 1? Leave it, 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 the password generator.
• Generating test data? Our UUID generator produces well-formed version-4 values for exactly this.