Why does .NET use a different format like {00000000-0000-0000-0000-000000000000}?

It doesn't — the value is identical. .NET's Guid type can render itself in five formats via the ToString() argument: 'D' (default 8-4-4-4-12 with hyphens), 'N' (32 hex digits, no hyphens), 'B' (with curly braces), 'P' (with parentheses), and 'X' (binary form with braces). The braces are a Windows convention; the underlying bytes are unchanged.

Can I use a GUID generated in .NET in a UUID library in Python?

Yes — strip the braces if present and pass the 36-character hyphenated form to uuid.UUID(). Both ecosystems agree on the canonical layout. The only commonly seen difference is byte order in binary form: .NET's Guid serializes the first three groups as little-endian on x86, which can surprise developers reading the raw bytes.

Should I write 'UUID' or 'GUID' in my codebase?

Match your stack. .NET / C# / SQL Server: GUID. Java, Python, Go, Rust, JavaScript, PostgreSQL, MySQL, MongoDB: UUID. New systems that span multiple languages should standardize on UUID since that's the term used in RFC 9562.

UUID vs GUID — Are They the Same Thing? (2026)

Where the two names came from

The 128-bit unique identifier was first standardized by the Open Software Foundation (OSF) for DCE (Distributed Computing Environment), which called it a UUID. When Microsoft adopted the format for COM and OLE in the 1990s, they branded it "GUID." Both names refer to the same byte layout, the same algorithm, and the same version semantics. Today RFC 9562 (May 2024) is the authoritative specification and uses the term UUID throughout.

Format conventions you'll see in the wild

The five .NET Guid format strings produce different textual renderings of the identical underlying bytes:

Guid g = Guid.Parse("550e8400-e29b-41d4-a716-446655440000"); g.ToString("D") // 550e8400-e29b-41d4-a716-446655440000 (default, hyphenated) g.ToString("N") // 550e8400e29b41d4a716446655440000 (no hyphens) g.ToString("B") // {550e8400-e29b-41d4-a716-446655440000} (braced) g.ToString("P") // (550e8400-e29b-41d4-a716-446655440000) (parens) g.ToString("X") // {0x550e8400,0xe29b,0x41d4,{0xa7,0x16,...}} (struct)

The byte-order gotcha

When serialized as raw bytes (not text), .NET'sGuid.ToByteArray()writes the first three groups in little-endian order, while RFC 9562 and most other languages use big-endian throughout. This bites developers who store Guids as binary in a non-Microsoft database and then read them with a different language. To avoid surprises, store UUIDs as text or as the RFC 9562 big-endian byte order; .NET 9 provides ToByteArray(bigEndian: true) for this.

Quick conversion

import uuid # All of these parse to the same value: uuid.UUID('550e8400-e29b-41d4-a716-446655440000') # canonical uuid.UUID('550e8400e29b41d4a716446655440000') # no hyphens uuid.UUID('{550e8400-e29b-41d4-a716-446655440000}') # braces uuid.UUID('urn:uuid:550e8400-e29b-41d4-a716-446655440000') # urn:

Frequently asked questions

Functionally, none. Both are 128-bit identifiers that follow the same RFC 9562 (formerly RFC 4122) format. 'GUID' (Globally Unique Identifier) is the term Microsoft adopted for its COM and .NET ecosystems in the 1990s. 'UUID' (Universally Unique Identifier) is the IETF/X.500 term used everywhere else. Tools that generate one will accept the other.