Formatting a UUID for a Windows or COM API

Formatting a UUID for a Windows or COM API

Windows APIs and COM specifications rarely accept a UUID in the same lowercase-with-hyphens form most web tooling expects. A CLSID registry key wants curly braces around the value. Some legacy interop code wants every hex digit uppercase. Getting this wrong does not throw a helpful error in most cases, it just silently fails to match the identifier the API was looking for. This guide generates a UUID and reformats it directly into the punctuation and casing these older, still-common interfaces actually expect.

Why Windows and COM expect a different shape

COM, Microsoft's Component Object Model, predates the modern web-tooling convention of lowercase, unbraced UUIDs by more than a decade. A GUID, a CLSID, and an IID are all the same underlying value as a UUID, but the functions that parse them from a string are not interchangeable: some, like IIDFromString, expect the braces to be present, while others accept the bare form.¹

Some interop layers go a step further and expect every hexadecimal character uppercase as well, a holdover from how GUIDs were traditionally written in C and C++ source code and registry export files. Neither convention is arbitrary; both trace back to how these identifiers were originally declared and displayed decades before UUIDs became a general-purpose web identifier.

What happens when the format does not match

A GUID comparison inside these older systems is frequently a literal string match rather than a value-aware comparison, so a value that is numerically identical but formatted differently, missing its braces, or in the wrong case, can fail to match without producing an obvious error message. That makes formatting mistakes some of the more frustrating bugs to track down in COM interop code, since the underlying 128-bit value is correct and the failure looks like a missing registration instead of a punctuation mismatch.

The five formats this tool produces, and where each belongs

Standard format, lowercase with hyphens, is the canonical RFC representation and the safest default for anything web-facing: REST APIs, log files, and most modern databases all expect this shape. UPPERCASE keeps the same hyphen placement but capitalizes every hex digit, matching what some older Windows APIs and enterprise systems that predate the RFC still require.

Braces wraps the standard form in curly braces, matching the exact shape a CLSID or IID takes inside the Windows registry and inside COM interface declarations, and the same shape .NET's own Guid.ToString("B") specifier produces.² No Hyphens strips all four separators down to a flat 32-character string, a form some databases and ORMs use internally to shave a few bytes off every stored identifier.

Picking Braces specifically for COM interop

For a COM interop task specifically, Braces is almost always the format you want: paste the generated value directly into a registry key, an IDL file, or a DEFINE_GUID macro, and the punctuation already matches what those contexts expect. Switching the format toggle here reformats the same underlying value instantly, so you never have to manually add or strip characters after copying. This page opens with Braces already selected, since that is the one format a COM or Windows registry task reaches for most often; the other four remain one click away if a different target system expects something else.

UPPERCASE stays a click away for the specific legacy systems that expect it, and combining the two, uppercase letters inside braces, is not one of the five preset formats here, since it is a rarer requirement than either convention on its own. If a specific interop layer needs that exact combination, generate the Braces form and apply the case change with a text editor's find-and-replace before pasting it in.

Formatting is reversible, generation is not

Every format on this page represents the exact same 128-bit value; switching the toggle only changes the surrounding punctuation and letter casing, never the underlying identifier. You can flip between Standard and Braces as many times as needed while matching a specific API's expectations, and the value you eventually copy will still be numerically identical no matter which format was active when you clicked Copy.

The fifth format, and how copying stays consistent across all five

URN, the fifth format, prefixes the value with urn:uuid: and belongs to a different world entirely: XML documents and RDF graphs that need a resolvable URI rather than a bare identifier, matching the registered URN namespace the UUID specification itself defines.³ It is worth knowing it exists even outside a Windows context, since some interop layers that bridge COM objects into web services expect exactly that URN form on the way out.

Copy behaves the same way regardless of which of the five formats is active: it copies exactly what is displayed in that row, character for character, with no trimming or reformatting applied afterward. That consistency means a Braces-formatted value pasted straight into a registry key never needs manual cleanup, and the same holds for any of the other four formats when a different target system is the one you are pasting into.

When to use this

Use this guide whenever a Windows registry key, a COM interface declaration, or a legacy interop layer expects a UUID in braces or uppercase instead of the standard lowercase-with-hyphens form.

Examples

Before: the registry key expects a value shaped like {6B29FC40-CA47-1067-B31D-00DD010662DA}, braces included.

Selecting the Braces format toggle here wraps the generated V4 value in curly braces automatically, producing a string you can paste directly into the registry key without manually adding the punctuation yourself.

Before: the interop code compares GUID strings case-sensitively and expects every hex digit uppercase.

Switching to the UPPERCASE format reformats the same value with every character capitalized, while the hyphen positions and the underlying 128 bits stay identical to the Standard form.