Tools Nimbus

UUID vs GUID: what is the difference

Tools Nimbus is a free, no-signup developer toolkit that runs entirely in your browser, so your data is never uploaded to a server. UUID and GUID are the same thing: a 128-bit identifier written in the 8-4-4-4-12 format. UUID is the open standard (RFC 9562); GUID is Microsoft's name for it. The only real gap is binary byte order. Generate standards-compliant version 4 UUIDs with our free UUID Generator.

Last updated June 2026

The short answer

A GUID is a UUID. The two acronyms name the same 128-bit value: a Universally Unique Identifier (UUID) and a Globally Unique Identifier (GUID) are both 32 hexadecimal digits grouped as 8-4-4-4-12, for example f47ac10b-58cc-4372-a567-0e02b2c3d479. The reason there are two words for one idea is purely historical. UUID is the vendor-neutral term defined by the IETF, while GUID is the name Microsoft chose when it built the identifier into Windows, COM, .NET, and SQL Server. If you generate a value as a UUID and someone else reads it as a GUID, nothing breaks, because the text is identical.

Side by side

PropertyUUIDGUID
Stands forUniversally Unique IdentifierGlobally Unique Identifier
Size128 bits128 bits
Text format8-4-4-4-12 hexSame 8-4-4-4-12 hex
Defined byRFC 9562 (obsoletes RFC 4122)Microsoft, following the same standard
Binary byte orderBig-endian for all fieldsFirst three fields often little-endian
Common inPostgreSQL, Java, Python, most languages.NET, SQL Server, the Windows API
Typical casingLowercaseOften uppercase, sometimes in braces
Interchangeable as textYesYes

The one real difference: byte order

The only place UUID and GUID genuinely part ways is the binary layout. RFC 9562 says that when a UUID is serialised to 16 bytes, every field is written in big-endian, also called network byte order. Microsoft's GUID structure instead stores the first three fields, the Data1, Data2, and Data3 members, in the native little-endian order of x86 processors, and only the final eight bytes in network order. The string you see on screen is the same either way, so the discrepancy stays hidden until you convert between the text form and raw bytes. Read a Microsoft GUID's bytes with a strict big-endian UUID parser and the first three groups come out byte-swapped, which is a classic source of mismatched identifiers between a .NET service and, say, a PostgreSQL uuid column. The fix is always to agree on byte order at the boundary, not to change how you generate the value.

Versions matter more than the name

When developers argue about UUID versus GUID, the decision that actually affects their system is usually the version, not the label. The same format carries a version digit, and the common choices are:

  • Version 4 (random): the default almost everywhere. It is generated from random bits, leaks nothing about the host or the time, and is supported by every platform. This is what our generator produces.
  • Version 7 (time-ordered): added in RFC 9562. It prefixes a millisecond timestamp so values sort roughly by creation time, which keeps database indexes compact and inserts sequential. A strong choice for primary keys.
  • Version 1 (time and node): embeds a timestamp and the machine's MAC address. Best avoided in new systems because it can leak where and when an identifier was created.

Whether your stack calls the result a UUID or a GUID, the version digit sits in the same place, so the performance and privacy trade-offs are identical across both names.

Casing and braces

One cosmetic difference trips people up. The UUID world tends to write values in lowercase, while Microsoft tooling often emits uppercase and sometimes wraps the value in curly braces, like {F47AC10B-58CC-4372-A567-0E02B2C3D479}. Both are the same identifier. Comparisons should be case-insensitive and should strip any surrounding braces first, otherwise two equal values can look different. If you are normalising identifiers from a mixed environment, a case converter makes it quick to force everything to one casing before you store or compare it.

Which should you use?

Use whichever term your platform uses, because the value is the same. Reach for a UUID or GUID whenever you need an identifier that two systems can generate independently without coordinating, such as primary keys, idempotency keys, correlation IDs across services, or file names that must not collide. Pick version 4 for a safe random default and version 7 when sortable keys help your database. The only time the UUID versus GUID distinction needs care is at a binary boundary, where you must match byte order. Everywhere else, generate one with our UUID Generator and treat the two names as synonyms.

Related reading and tools

Generating identifiers in bulk is one job; if you also need cryptographically strong secrets, see the Password Generator, and for checksums and fingerprints use the Hash Generator. For a head-to-head with a popular online generator, read free alternative to UUIDGenerator.net, and if you care about where else random values matter, see the best free offline password generator. Browse the full set of tutorials on the Tools Nimbus guides index.

Frequently asked questions

What is the difference between a UUID and a GUID?+

For almost all practical purposes there is no difference: a GUID is Microsoft's name for a UUID. Both are 128-bit identifiers written as 32 hexadecimal digits in the 8-4-4-4-12 grouped format, and both follow the same standard, now RFC 9562. The only real divergence is in the binary representation. Microsoft's GUID has historically stored the first three fields in little-endian byte order, while a standard UUID stores every field in big-endian order. The human-readable string is identical, so if you only ever pass them around as text, UUID and GUID are interchangeable.

Are UUID and GUID the same thing?+

Yes, in the sense that matters most. They describe the same 128-bit identifier and the same canonical string format, so a value generated as a UUID is a valid GUID and vice versa. The terms come from different lineages: UUID is the vendor-neutral term used by RFC 9562, PostgreSQL, Java, and most languages, while GUID is the term Microsoft uses across .NET, SQL Server, and the Windows API. Treat them as two names for one concept, and only worry about the distinction when you serialise to raw bytes.

Why do UUID and GUID byte order differ?+

The difference is historical. When Microsoft adopted the identifier, it stored the first three fields of the structure using the native little-endian byte order of x86 processors, which was efficient at the time. RFC 9562 instead mandates big-endian (network) order for every field so the value is portable across architectures. The mismatch only surfaces when you convert between the text form and a 16-byte binary blob: read a Microsoft GUID's bytes with a strict big-endian UUID parser and the first three groups come out byte-swapped. Always confirm which byte order a binary store or API expects.

Should I use UUID or GUID in my database?+

Use whatever your platform calls it; the underlying value is the same. PostgreSQL has a native uuid type, SQL Server has uniqueidentifier (its GUID type), and both store a 128-bit value. The choice that actually affects performance is the version, not the name: random version 4 values scatter across an index and can fragment it, while a time-ordered version 7 value sorts roughly by creation time and keeps inserts sequential. If you control the schema and care about write throughput, prefer version 7 for primary keys.

Which UUID version should I generate?+

Version 4 is the safe default: it is purely random, reveals nothing about the machine or time that created it, and is supported everywhere. Choose version 7 when you want identifiers that are still unique but also sortable by creation time, which improves database index locality. Avoid version 1 in new systems because it embeds a timestamp and the network card's MAC address, which can leak information. Our generator produces standards-compliant version 4 UUIDs that work anywhere a GUID is expected.

Try these browser-based tools mentioned in this guide. Everything runs locally, so your data never leaves your device.