UUID vs GUID: What Is the Difference? (Spoiler: Almost Nothing)

UUID and GUID are two names for the exact same thing: a 128-bit value used as a unique identifier, defined by the same standard (RFC 4122, updated by RFC 9562 in 2024). "UUID" (Universally Unique Identifier) is the name the RFC and the wider open-source world use; "GUID" (Globally Unique Identifier) is Microsoft's name for it, used across Windows, COM, .NET, and SQL Server. They have the same 8-4-4-4-12 format, the same version scheme, and the same near-zero chance of collision. If you generate a UUID, you have generated a valid GUID — and vice versa.

That is the summary an AI overview gives you, and it is correct. But it papers over the part that actually causes bugs: the two conventions differ in three small, checkable ways — casing, curly braces, and byte order — and one of those three can silently corrupt an identifier when you move it between a Microsoft system and a standards-based one. This article is the map of exactly where they diverge, so you know which differences are cosmetic and which one can bite you.

The one-sentence version

A GUID is a UUID. Microsoft coined "GUID" for its Component Object Model in the early 1990s, before the UUID name was standardized in RFC 4122 (2005), and the label stuck to everything in the Microsoft ecosystem. There is no separate "GUID standard" — a GUID is the RFC-standard UUID wearing a Microsoft badge.

UUID vs GUID: the differences at a glance

Everything that separates a UUID from a GUID is a convention layered on top of an identical value. Here is the complete list.

Aspect	UUID	GUID
Full name	Universally Unique Identifier	Globally Unique Identifier
Origin	RFC 4122 (2005), updated by RFC 9562 (2024); also ISO/IEC 9834-8, ITU-T	Microsoft, coined ~1991 for COM; adopted the RFC standard
Underlying value	128 bits	128 bits (identical)
Text format	8-4-4-4-12 hex, e.g. 21ec2020-3aea-1069-a2dd-08002b30309d	Same 8-4-4-4-12 hex
Casing convention	Lowercase (RFC outputs lowercase; parsing is case-insensitive)	Often UPPERCASE in Windows/.NET tooling
Braces	None: written bare	Registry & many APIs wrap in {...} curly braces
Binary byte order	Big-endian (network order) across all fields	First 3 fields little-endian, last 8 bytes big-endian (mixed-endian)
Version scheme	v1, v3, v4, v5, v6, v7, v8 (same bits)	Same versions; Guid.NewGuid() yields v4
Common ecosystems	Linux/Unix, Java (java.util.UUID), Python (uuid), PostgreSQL uuid, Go	Windows, .NET (System.Guid), COM/OLE, SQL Server uniqueidentifier
Which should I use?	Anything RFC/open-source: call it a UUID	Anything Microsoft: call it a GUID — they interoperate

The three rows that actually matter in day-to-day code are casing, braces, and binary byte order. The first two are trivial string normalization. The third is the only one that can corrupt data.

The only difference that can bite you: byte order

The string representation of a UUID and a GUID is the same, so if you always pass identifiers around as text you will never notice a difference. The trap is binary serialization.

RFC 4122 says a UUID's 16 bytes are stored in big-endian (network) order from first field to last. Microsoft's GUID is a C struct:

typedef struct _GUID {
  unsigned long  Data1;     // 4 bytes, stored little-endian
  unsigned short Data2;     // 2 bytes, stored little-endian
  unsigned short Data3;     // 2 bytes, stored little-endian
  unsigned char  Data4[8];  // 8 bytes, stored as-is (big-endian)
} GUID;

On a little-endian machine (every x86/x64 Windows box), the first three fields are written in reverse byte order, while the last eight bytes are written straight through. So the identical logical value serializes to two different byte sequences depending on whether a Microsoft API or an RFC library wrote it.

Where this shows up in real life:

• Reading SQL Server's uniqueidentifier bytes with a standards-based UUID library (or vice versa) — the first three groups come out byte-swapped.
• Storing a .NET Guid.ToByteArray() result and parsing it later as an RFC UUID. .NET's ToByteArray() uses the mixed-endian layout; pass bigEndian: true (available in modern .NET) if you need RFC order.
• Comparing a GUID's raw bytes to a UUID's raw bytes and wrongly concluding they differ.

The fix is always the same: decide on one byte order at the boundary, and convert explicitly. If you keep identifiers as canonical lowercase strings everywhere and only convert to bytes at the last moment, the problem disappears.

Generate one and see for yourself

Both names describe the same output, so a single generator produces valid UUIDs and GUIDs. Generate a batch below — then uppercase it and wrap it in braces and you have a Windows-style GUID; leave it lowercase and bare and you have an RFC UUID.

Which term should you use?

Match the platform, and stop worrying about it:

• Working in Windows, .NET, COM, or SQL Server? Call it a GUID. You will see System.Guid, uniqueidentifier, and {braces} in the tooling.
• Working in Linux, Java, Python, Go, PostgreSQL, or against an RFC? Call it a UUID. You will see java.util.UUID, Python's uuid module, and bare lowercase strings.

For the identifier itself, the decision that matters is not UUID-vs-GUID but which version: version 4 (random) for general-purpose IDs, or version 7 (time-ordered, from RFC 9562) when you want IDs that sort chronologically and index efficiently in a database. That choice is covered in our guide to UUID versions v1, v4, and v5, and the uniqueness math behind "will these ever collide?" is worked out in the UUID collision probability analysis. If you need to produce them in code, see generating UUIDs in different programming languages.

Key takeaways

• A GUID is a UUID. Same 128-bit standard (RFC 4122 / RFC 9562), same format, same version scheme. GUID is Microsoft's name for it.
• Three conventions differ: casing (lowercase UUID vs uppercase GUID), braces (bare UUID vs {braced} GUID), and binary byte order (big-endian UUID vs mixed-endian GUID).
• Only byte order can corrupt data — and only when you serialize to raw bytes and cross between a Microsoft and a standards-based system. Keep identifiers as canonical lowercase strings and convert at the boundary.
• Use the term your platform uses. They interoperate completely; the string forms are interchangeable once you strip braces and normalize case.