UUID vs GUID: What's the Difference?

The Short Answer

A UUID (Universally Unique Identifier) and a GUID (Globally Unique Identifier) are two names for the same underlying concept: a 128-bit value used to uniquely identify information without central coordination. Both use the familiar hyphenated 36-character format:

6f9619ff-8b86-d011-b42d-00c04fc964ff

The two terms come from different standards bodies and ecosystems:

• UUID was defined by the Open Software Foundation in the 1980s, then formalised by the IETF in RFC 4122. It is the term used by Linux, macOS, Java, Python, JavaScript, Go, Rust, PostgreSQL, MySQL, MongoDB, and most of the wider software world.
• GUID is Microsoft's implementation of the same idea, introduced in Windows and used throughout COM, .NET, SQL Server, Visual Studio, and the Windows Registry.

For the overwhelmingly common version-4 (random) case, UUIDs and GUIDs are functionally identical. You can generate a GUID in C#, ship the string to a Linux backend, store it in a PostgreSQL uuid column, and never see a problem.

Where They Actually Differ

There are three concrete differences worth knowing about.

1. Byte Order (Endianness) in v1 Values

This is the only real technical difference. RFC 4122 specifies that all fields of a UUID are stored in big-endian byte order when serialized to a byte array. Microsoft's Guid.ToByteArray() method, however, stores the first three fields in little-endian order. This only matters if you are comparing raw bytes across systems.

Take this v1 UUID: 6F9619FF-8B86-D011-B42D-00C04FC964FF

Serialized per RFC 4122 (big-endian):

6F 96 19 FF 8B 86 D0 11 B4 2D 00 C0 4F C9 64 FF

Serialized by Guid.ToByteArray() in .NET (little-endian first three fields):

FF 19 96 6F 86 8B 11 D0 B4 2D 00 C0 4F C9 64 FF

The string form is identical; only the raw byte layout is swapped. If you store a SQL Server uniqueidentifier value into another database byte-for-byte, you can end up with an apparently different UUID. Guid.ToString() and new Guid(byte[]) both apply the swap internally, so it is invisible unless you reach for the bytes directly.

2. Curly Braces

Microsoft tooling frequently wraps GUIDs in curly braces — {6f9619ff-8b86-d011-b42d-00c04fc964ff} — in the Registry, COM class IDs, Visual Studio project files, and PowerShell output. The braces are a display convention, not part of the identifier. RFC 4122 does not use them. When parsing, strip the braces first (.NET, Guid.Parse(), and most parsers accept either form).

3. Ecosystem Vocabulary

This is less a technical difference and more a cultural one, but it causes confusion. Naming conventions by ecosystem:

C# / .NET          → Guid
SQL Server         → uniqueidentifier
PowerShell         → [guid]::NewGuid()

Java               → UUID (java.util.UUID)
Python             → uuid (uuid module)
JavaScript / Node  → crypto.randomUUID()
Go                 → uuid.UUID
Rust               → Uuid (uuid crate)
PostgreSQL         → uuid
MySQL 8+           → UUID()
MongoDB            → UUID BSON type

If a .NET codebase calls it a GUID and a JVM codebase calls it a UUID, they can still exchange values freely as strings. Pick the name your platform uses and move on.

What's the Same: The Structure

Both UUIDs and GUIDs share the same 128-bit layout, split into five groups separated by hyphens:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
└─time-low┘ └tm┘ └tm┘ └cs┘ └─node/random──┘
                 ^    ^
                 |    variant bits (N)
                 version (M)

The two key bits are:

• Version (M) — the first hex digit of the third group indicates the version: 1 for time-based, 3 and 5 for namespace-based hashes, 4 for random, 7 for time-ordered random (the newest, added in RFC 9562).
• Variant (N) — the first bits of the fourth group identify the layout standard. 8, 9, A, or B means RFC 4122 / RFC 9562 layout. Other variants exist for legacy Microsoft and NCS GUIDs but are rarely encountered today.

Try our UUID generator to see real values with the version bits set.

Practical Tradeoffs

If you are deciding between "UUID" and "GUID" libraries in code, the choice is almost never about the identifier itself — it is about the version of the identifier. The real decisions to make:

v4 vs v7

Use v4 when you want purely random, unguessable IDs. Use v7 (time-ordered UUIDs, standardised in RFC 9562 in 2024) when you are using the ID as a database primary key — the time prefix means new inserts go to the end of the B-tree index, avoiding the fragmentation and cache-thrashing problems that v4 causes at scale.

String vs Binary Storage

Storing UUIDs as 36-character strings is easy but wastes space (36 bytes per row). PostgreSQL's uuid type and SQL Server's uniqueidentifier both store them as 16 bytes. For MySQL, use BINARY(16) with UUID_TO_BIN(uuid_str, swap_flag) — and yes, the swap flag is there specifically because of the big-endian/little-endian difference described above.

Exposing IDs Publicly

Both UUIDs and GUIDs are safe to expose in URLs and APIs — they do not reveal record count or creation order (for v4) and they cannot be enumerated. If you need ordering, prefer v7. If you want something shorter, consider alternatives like ULID or NanoID, which keep most of the uniqueness guarantees but produce more compact strings.