UUID vs GUID

Updated April 26, 2026 · 5 min read · by Samuel Yoo

TL;DR. UUID and GUID are the same 128-bit identifier defined by the same RFC. “GUID” is Microsoft’s name for it. There’s one historical wrinkle: Microsoft’s binary serialization order differs from everyone else’s. Otherwise they’re interchangeable.

Is a GUID the same as a UUID? Yes. They’re the same 128-bit value in the same format; GUID is simply Microsoft’s name for a UUID.

They’re the same thing

Both UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) refer to a 128-bit number, almost always written as 32 hex characters in five groups separated by hyphens:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

The M nibble encodes the version (1, 3, 4, 5, 7, …) and the top bits of the N nibble encode the variant (which family of UUID specs the value belongs to). The rest is either timestamp, randomness, or hash bytes depending on the version.

The standard is RFC 4122 (2005), updated by RFC 9562 (2024) which added v6, v7, v8, and the max UUID.

Why two names?

Microsoft adopted UUIDs early (in COM/OLE in the early ’90s) and called them GUIDs. The name stuck inside the Windows ecosystem: .NET’s type is System.Guid, SQL Server’s column type is uniqueidentifier (with NEWID() generating one), and the Win32 API exposes CoCreateGuid. Outside Windows — in the JVM, in Postgres, in Linux, in JavaScript — the name is “UUID”.

When you see a 128-bit hex identifier in the wild, you can treat the two names as synonyms. There’s no behavior difference at the value level.

UUID vs GUID: the differences at a glance

Braces and capital letters are display habits, not part of the value. .NET, Postgres and Python accept either form, but some parsers, like Java’s UUID.fromString, need the braces removed first.

The byte order gotcha

There’s exactly one place the names matter: binary serialization.

• RFC 4122 (“network order”) — the bytes are laid out in the order you’d read them: timestamp-low (4 bytes), timestamp-mid (2 bytes), timestamp-high-and-version (2 bytes), clock-seq (2 bytes), node (6 bytes). This is what almost every non-Microsoft system uses.
• Microsoft GUID format — the first three groups (timestamp-low, mid, high) are stored in little-endian order on disk. The last two groups are byte-for-byte identical.

So the same value 00112233-4455-6677-8899-aabbccddeeff serializes as:

RFC 4122:    00 11 22 33  44 55  66 77  88 99  aa bb cc dd ee ff
Microsoft:   33 22 11 00  55 44  77 66  88 99  aa bb cc dd ee ff

If you’re parsing GUIDs from a Windows binary file, an OLE document, or a SQL Server uniqueidentifier extracted as bytes, you need to byte-swap the first three groups. If you’re working with the canonical hex string, you don’t.

In code

GUIDs in C# and .NET

In .NET a UUID is System.Guid. Create a random one with:

Guid id = Guid.NewGuid();            // random (v4)
Console.WriteLine(id);               // 3f2504e0-4f89-41d3-9a0c-0305e82c3301
Console.WriteLine(id.ToString("B")); // {3f2504e0-4f89-41d3-9a0c-0305e82c3301}

On .NET 9 and later, Guid.CreateVersion7() gives you a time-ordered v7 value, which is the better choice for database keys. Guid.Parse reads the string from any other platform, with or without braces. For formats, parsing and Entity Framework tips, see GUIDs in C#.

Should I worry about the difference?

For 99% of work: no. If your stack is end-to-end string-based (UUIDs in JSON, in URLs, as text columns), the names mean nothing and the values move freely between systems.

The one case to think carefully about:

Storing UUIDs as binary(16) in SQL Server and reading them back from another platform.

SQL Server stores them in Microsoft order. If you read those bytes from C# the byte order is hidden behind Guid’s parsing logic and everything works. If you read those same bytes from a Java or Python migration script, you’ll see the first three groups byte-swapped and the strings will look wrong. Convert via the canonical hex form, not raw bytes, when crossing platform boundaries.

Practical advice

• Pick one name in your codebase and docs. Most non-Microsoft projects use “UUID” even when interoperating with Windows.
• Use the canonical hex string (with hyphens) when serializing to JSON, URLs, logs, or any cross-system format. It dodges the byte-order issue entirely.
• Use v7 for new primary keys (see UUID v7).
• Use v4 for everything else (see the main generator).
• Never assume a third-party “GUID” field uses RFC byte order without checking — especially if it’s coming from older Microsoft systems.

FAQ

Are GUID and UUID the same?

Yes. A GUID is a UUID. Both are 128-bit identifiers in the same format, and a value made by Guid.NewGuid() is a valid UUID anywhere else.

What’s the difference between a UUID and a GUID?

Only the name and a few conventions. Microsoft says GUID and often writes it in capitals with braces, and it stores the first three groups little-endian when the value is saved as raw bytes. As a string, the two are interchangeable.

Can I use a GUID where a UUID is expected?

Yes. Pass it as the standard hyphenated string and Postgres, Java and Python will read it as a UUID, and JavaScript will treat it as a valid UUID string. Only raw 16-byte values need the first three groups byte-swapped.

Which should I say, UUID or GUID?

Use whatever your stack uses: GUID in .NET and SQL Server code, UUID everywhere else. In mixed teams, UUID is the standard term.

Try it

The UUID generator on this site speaks both names equally — output is the canonical hex string, which works as both a UUID and a GUID anywhere.