Formatting a UUID for a Windows or COM API

Generate a UUID and format it in braces or uppercase for Windows registry keys, COM interfaces, and legacy interop code that expects that shape.

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.

Run this check yourself in the UUID v1, v4 & v7 Generator.

Open in the tool →

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.1

The layout itself has been stable since the DCE era: a GUID is 128 bits written as one group of 8 hexadecimal digits, three groups of 4, and one final group of 12, which is exactly the 8-4-4-4-12 arrangement the standard form uses.2

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. A GUID's string form is not unique: it can be 32 case-insensitive hexadecimal digits, those digits with internal hyphens, or the whole thing wrapped in braces or parentheses, and .NET's System.Guid.Parse additionally accepts a braced 0x-prefixed form that a naive strip-everything-non-hex comparison will mis-parse.3 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.4 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.5 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

Registering a new CLSID in the Windows registry

Before
Before: the registry key expects a value shaped like {6B29FC40-CA47-1067-B31D-00DD010662DA}, braces included.
After
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.

A legacy interop layer rejecting a lowercase GUID

Before
Before: the interop code compares GUID strings case-sensitively and expects every hex digit uppercase.
After
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.
Sources
  1. 1.

    Raymond Chen, "What's the difference between UuidFromString, IIDFromString, CLSIDFromString, GUIDFromString...," devblogs.microsoft.com, October 2015. https://devblogs.microsoft.com/oldnewthing/20151015-00/?p=91351

  2. 2.

    Microsoft, "GUID Structure (guiddef.h)," Win32 apps, learn.microsoft.com, accessed October 2026. https://learn.microsoft.com/en-us/windows/win32/api/guiddef/ns-guiddef-guid

  3. 3.

    Raymond Chen, "How can I check if two GUIDs are equal when they are provided as strings?," The Old New Thing, devblogs.microsoft.com, December 2024. https://devblogs.microsoft.com/oldnewthing/20241225-00/?p=110677/

  4. 4.

    Microsoft, "Guid.ToString Method (System)," .NET API Browser, learn.microsoft.com, accessed August 2026. https://learn.microsoft.com/en-us/dotnet/api/system.guid.tostring?view=net-10.0

  5. 5.

    P. Leach, M. Mealling, R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace," RFC 4122, IETF, July 2005. https://www.rfc-editor.org/info/rfc4122

FAQ

Only the display. Braces adds two characters, { and }, around the exact same standard-form string; the 128-bit value they represent is unchanged. Any system that strips the braces before comparing will still see the identical GUID underneath.

Most REST APIs and modern JSON schemas expect the RFC's canonical lowercase-with-hyphens form. Older Windows and COM interfaces predate that convention and often do a literal string comparison against a braced, sometimes uppercase, format, so the same identifier that passes one system can silently fail to match in the other.

Functionally, yes. GUID, Globally Unique Identifier, is Microsoft's name for the same 128-bit value defined in the UUID specification. The formats differ by convention rather than by any structural difference in the underlying bits.

This tool generates a valid v1 UUID, but the node field uses cryptographically random bytes with the multicast bit set rather than a real MAC address, since browsers expose no MAC address through any API. That satisfies RFC 4122's fallback recommendation, but it will not match a system that specifically validates the node field against a known hardware address.

No. CapyToolkit reformats the same generated value client-side the instant you click a different format button, without calling the random generator again, so the underlying identifier and its entropy never change when you switch formats.

URN prepends urn:uuid: to the standard lowercase form, which is the registered URI scheme for UUIDs. Reach for it in XML documents or RDF graphs that need a resolvable URI rather than a bare value; for Windows registry keys and COM declarations, Braces is the format actually expected.

Additional resources

Guides

Generating a UUID for a Session Token or CSRF Nonce Generate a cryptographically random UUID for a session ID or CSRF nonce, and see why Math.random() is the wrong source for either one. Formatting a UUID for a Windows or COM API Generate a UUID and format it in braces or uppercase for Windows registry keys, COM interfaces, and legacy interop code that expects that shape.