UUID vs GUID: What's the Difference?

A UUID and a GUID are the same thing. UUID is the official standard term. GUID is Microsoft's name for it. Same format, same purpose, different badge.

That's the answer most posts bury in paragraph four. But there's more worth knowing — what these IDs actually are, why version matters, and when you should be using them in your projects.

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit identifier formatted as 32 hexadecimal characters split into five groups: 550e8400-e29b-41d4-a716-446655440000. It's designed to be unique across every system, everywhere, without any central authority assigning them. You generate one locally — no database check, no API call, no coordination with anyone.

A GUID (Globally Unique Identifier) is Microsoft's implementation of the same spec. If you're in a .NET or SQL Server codebase, you'll see GUID everywhere. If you're in everything else, you'll see UUID. They're interchangeable.

Why unique identifiers exist

Databases need to identify rows. The obvious approach is an auto-incrementing integer: 1, 2, 3, 4. Simple, fast, totally fine — until it isn't.

Auto-increment breaks the moment you have more than one database. Merge two tables and you've got two rows with ID 1. Shard your data across servers and you need a central ID allocator, which becomes a bottleneck and a single point of failure. Expose those IDs in URLs and you've just told users exactly how many records you have.

UUIDs solve all of this. They're generated independently — on your server, in your app, on a client device — and the probability of two matching is so low it's effectively impossible. The number is 2^122 possible v4 UUIDs. If you generated one billion per second for the next hundred years, you'd still have a less than 50% chance of a collision.

UUID versions — which one to use

There are eight UUID versions. You'll only ever need to think about two.

Use v4 unless you have a specific reason not to. It's what every UUID generator defaults to, it's what most libraries generate by default, and it's what the rest of your team will expect.

The one case to consider v7: if you're inserting a lot of UUIDs into a database index, v4's randomness causes index fragmentation — rows get inserted all over the place instead of at the end. V7 is time-ordered, which keeps inserts sequential and improves performance. But unless you're at serious scale, v4 is fine.

What a UUID looks like — dissected

Here's a real v4 UUID: f47ac10b-58cc-4372-a567-0e02b2c3d479

It breaks down into five groups separated by hyphens:

• f47ac10b — 8 hex characters
• 58cc — 4 hex characters
• 4372 — 4 hex characters (the 4 at the start indicates version 4)
• a567 — 4 hex characters (the a or b at the start indicates it's RFC 4122 compliant)
• 0e02b2c3d479 — 12 hex characters

The version digit (position 13) and variant bits (position 17) are the only non-random parts in a v4 UUID. Everything else is random. That's 122 bits of randomness — which is why collisions are practically impossible.

UUID vs GUID — the only real difference

That's it. If someone sends you a GUID, you can use it anywhere a UUID is expected. If your .NET colleague asks for a UUID, hand them a GUID. Same thing.

The one gotcha: some Microsoft tools default to uppercase (F47AC10B-58CC-4372-A567-0E02B2C3D479). Most UUID validators are case-insensitive, but be consistent within your own system. Pick lowercase and stick with it — same principle as UTM parameter naming conventions.

When to use UUIDs — and when not to

Use a UUID when:

• You're working with distributed systems or multiple databases
• You're syncing data between a client app and a server before it hits the database
• You don't want to expose sequential IDs in URLs (UUIDs don't reveal record counts)
• You're generating IDs on the client side (mobile apps, offline-first apps)
• You're building a public API where internal IDs would be a security leak

Don't use a UUID when:

• You need human-readable IDs — UUIDs are not readable or memorable
• Storage size matters a lot — a UUID stored as a string is 36 bytes vs 4–8 bytes for an integer
• You're building a tiny internal tool with one database and no plans to scale — a regular auto-increment is simpler and there's nothing wrong with it

The mistake developers make is treating UUIDs as the always-correct default. They're not. An integer primary key is faster to index, smaller to store, and easier to reason about. Choose UUIDs when you actually need their properties.

Common mistakes with UUIDs

Storing UUIDs as strings. Most databases have a native UUID type — use it. Storing f47ac10b-58cc-4372-a567-0e02b2c3d479 as a VARCHAR(36) takes 36 bytes and slows down index lookups. A native UUID column stores it as 16 bytes. Nine times out of ten, developers new to UUIDs make this mistake.

Using v1 in a public-facing system. UUID v1 includes your server's MAC address in the identifier. That's a minor information leak — not catastrophic, but unnecessary. Use v4 instead.

Mixing UUID formats in the same system. Some code generates lowercase UUIDs, some generates uppercase, some strips the hyphens. Your database ends up with f47ac10b-58cc-4372 sitting next to F47AC10B58CC4372 and your queries break. Standardise on one format and enforce it with validation at the input layer.

Assuming UUIDs are unguessable for security purposes. UUID v4 is random, not cryptographically secure. Don't use it as a password reset token or an API secret key. Use a proper cryptographic random generator for anything security-critical.

UUIDs aren't complicated once you stop treating them as magic. They're random strings with a specific format, designed to be unique without coordination. Use v4, store them in a native UUID column, and pick one case convention for your whole system.

If you need one right now, the UUID generator builds one instantly.