GUID vs UUID: Are They the Same Thing?

Somewhere in your career a teammate will insist that GUIDs and UUIDs are different, and you'll waste twenty minutes trying to convert one into the other. Save yourself the trouble: they're the same thing. A GUID is a UUID. The name changed, the value didn't — and the handful of differences that do exist are cosmetic, not structural.

The myth: two different ID formats

It's an easy assumption. One codebase generates 'GUIDs,' another generates 'UUIDs,' the acronyms are different, and Microsoft's tooling even prints them wrapped in curly braces. So it looks like two competing standards you have to translate between.

You don't. Both are a 128-bit number written as 32 hexadecimal digits in the same 8-4-4-4-12 grouping, with the same bits reserved to mark the version and variant. Paste one into a field expecting the other and it just works.

The evidence: same standard, two names

The identifier was standardized as a UUID — universally unique identifier. Microsoft implemented the very same thing for COM and Windows and called its version a GUID — globally unique identifier. Two organizations, two names, one 128-bit format. There was never a second specification to reconcile.

A quick way to see it: generate a random UUID and a random GUID from any two libraries and lay them side by side. Same length, same hex, same dashes. The UUID Generator labels its output 'UUID'; a .NET Guid.NewGuid() labels the identical bytes 'GUID.'

The generic-drug analogy

Think of acetaminophen. In the United States it's sold as Tylenol; in much of the rest of the world the same molecule is paracetamol. Different name on the box, different marketing, exactly the same compound doing exactly the same job. GUID is Microsoft's brand name; UUID is the generic name. Nobody asks a pharmacist to 'convert' paracetamol into acetaminophen, and you don't need to convert a GUID into a UUID.

The differences that actually remain

Same value doesn't mean zero differences — just that they're skin-deep:

• Casing. Microsoft tends to print GUIDs in uppercase (6F9619FF-...); most UUID tooling prints lowercase (6f9619ff-...). Hex is case-insensitive, so the value is identical — but a naive string comparison will call them different. Compare normalized case, not raw text.
• Curly braces. The Windows registry and some APIs wrap GUIDs in braces: {...}. That's presentation, not data. Strip the braces and you have a plain UUID string.
• Byte order (the one real trap). Legacy version 1 GUIDs stored their first three fields in little-endian byte order, while the UUID spec is big-endian. For random version 4 values this never matters, but if you're migrating old time-based GUIDs into a system that reads them big-endian, the bytes can reshuffle into a different-looking value. Check the ordering before you trust a bulk conversion.

Versions apply to both

Because they're the same format, the version system is shared. A GUID can be version 4 (random), version 5 (name-based), or the newer version 7 (time-ordered) exactly like a UUID — the trade-offs are the same ones covered in UUID v4 vs v7. When someone says 'random GUID,' they mean a version 4 UUID. When they worry about random keys fragmenting a database index, the same UUID vs auto-increment reasoning applies unchanged.

Which term should you use?

Match your platform's vocabulary so your code reads naturally:

• GUID if you're in .NET, SQL Server, Windows, or COM — that's what the APIs and docs call it.
• UUID everywhere else — Postgres, Java, Python, Ruby, Go, and the broader web all use this name.

Either way you generate them the same way and store the same 128 bits. If you want the full tour of what those bits mean and where the format came from, what is a UUID walks through it. And if you've ever wondered whether two of these could ever come out the same, are UUIDs unique? does the collision math.

The takeaway

GUID versus UUID isn't a real contest — it's one 128-bit identifier wearing two names, the way Tylenol and paracetamol are one drug. Ignore the casing and the curly braces, watch the byte order only when you're moving old version 1 values across systems, and otherwise treat them as interchangeable. Generate v4 for random IDs or v5 for name-based ones with the UUID Generator, call the result whatever your stack calls it, and move on.