UUIDs and GUIDs Explained: Formats, Versions, and When to Use Them

Runs 100% in your browser — nothing on this page is uploaded or stored. Strings like 6f1e9b2a-4c3d-4e5f-8a7b-9c0d1e2f3a4b show up in databases, APIs, config files, and URLs everywhere. They're UUIDs — and this guide explains what they are, how the versions differ, what a GUID is, and the practical rules for when to reach for one (and when not to).

What a UUID is

A UUID (Universally Unique Identifier) is a 128-bit identifier, standardized in RFC 4122 and updated by RFC 9562. The "universally unique" part is the whole point: the identifier is designed so that anyone, anywhere, can generate one without checking with anyone else, and the chance of two people generating the same one is so small it's not worth worrying about.

The standard text format is 32 hexadecimal digits in five groups separated by hyphens — the famous 8-4-4-4-12 pattern:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (36 characters including hyphens)

Hex digits are case-insensitive, but lowercase is the convention — you'll see 6f1e9b2a-… far more often than 6F1E9B2A-…. If you're normalizing a list of mixed-case UUIDs (from logs, exports, or API responses), our case converter will lowercase them all in one pass.

UUID vs GUID: what's the difference?

GUID (Globally Unique Identifier) is Microsoft's term for the same concept. In practice, a GUID is a UUID — specifically, Microsoft's implementation historically followed the version-4 (random) layout with a particular byte ordering. If someone asks for a "GUID generator" and someone else asks for a "UUID generator," they need the same thing: a 128-bit random identifier in the 8-4-4-4-12 format. The two terms are interchangeable in everyday developer conversation.

The versions, and which one you actually want

The third group's first digit encodes the version — how the UUID was generated. The common ones:

• Version 1 — time-based. Combines a timestamp with the machine's MAC address. Unique and roughly time-ordered, but it leaks when it was created and which machine created it. Mostly legacy now.
• Version 4 — random. 122 bits of randomness (6 bits are reserved for version and variant markers). This is the default "just give me a UUID" choice, and what crypto.randomUUID() in browsers produces.
• Version 5 — name-based (SHA-1). Deterministic: the same namespace + name always produces the same UUID. Useful when you need a stable identifier derived from existing data.
• Version 7 — time-ordered. New in RFC 9562 (2024). Puts a Unix timestamp first, then random bits — so UUIDs sort chronologically while staying unique. Increasingly the best choice for database primary keys, because time-ordered keys keep database indexes efficient.

The practical rule: use version 4 unless you have a reason not to; use version 7 if the IDs will be database keys at scale; use version 5 when you need the same input to always produce the same ID.

How unique is "universally unique," really?

A version-4 UUID has 122 random bits, which means 2¹²² — about 5.3 × 10³⁶ — possible values. The collision math is the birthday problem: you'd need to generate roughly 2.7 quintillion (2.7 × 10¹⁸) UUIDs before reaching even a 50% chance of a single duplicate. At a billion UUIDs per second, that takes about 85 years.

One honest caveat: this assumes a good random source. UUIDs generated from a weak pseudorandom generator (or a broken one) can collide far more often. In the browser, crypto.randomUUID() uses the operating system's cryptographic randomness — the same kind our password generator relies on — so it's sound. A UUID built from Math.random() is not a real v4 UUID and shouldn't be treated as one.

When to use UUIDs

• Distributed systems. Multiple servers or devices creating records independently, with no central counter to hand out IDs — the original motivation for UUIDs.
• Database primary keys when records are created across services or merged from different sources. (Prefer v7 for large tables.)
• Unpredictable identifiers — upload tokens, password-reset links, API keys. Randomness means they can't be guessed by incrementing.
• Filenames for user uploads, where collisions would overwrite someone else's file.

When NOT to use them

• User-facing IDs. Nobody wants to read 6f1e9b2a-4c3d-4e5f-… over the phone. Use short, human-friendly codes for anything a person will see or type.
• Sequential numbering. Invoice numbers, order numbers, and anything where gaps or order matter should be sequential — UUIDs are unordered (except v7) and reveal nothing about sequence.
• Short URLs. 36 characters is a lot of URL. Compact alternatives like Nano ID exist for this; or strip the hyphens for a 32-character form.
• Tiny embedded systems where 16 bytes per ID actually matters. Count your bytes before defaulting to UUIDs.

Formatting and validating UUIDs

A few practical notes that save debugging time:

• Hyphens are optional in storage. The 32-hex-digit form without hyphens is the same UUID. Strip them for compact storage, add them back for display.
• Validate with a pattern, not by length. A proper check is the regex ^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$ (case-insensitive) — this catches truncated or malformed IDs that a length check would miss.
• Normalize case before comparing. 6F1E… and 6f1e… are the same UUID, but a string comparison says otherwise. Lowercase everything on input — again, the case converter handles batches.
• Cleaning pasted lists: UUIDs copied from logs often come with extra whitespace, blank lines, or duplicates. Run the list through our text cleaner to trim lines and remove empties before processing.

Frequently asked questions

Tidy up your identifiers

Working with batches of UUIDs? Normalize their case, clean up pasted lists — free, instant, and everything stays in your browser.