UUID / GUID Generator
Generate all eight standard UUID formats — including the newer sortable v6 and v7 — plus a paste-in decoder that reads the version, variant and embedded timestamp out of any existing UUID. Runs entirely in your browser.
Click Generate to create a batch of UUIDs
Picking the Right Version, Not Just the Familiar One
- Default to v4 unless something specific says otherwise. Pure randomness with no encoded information is the right choice for almost every general-purpose identifier, and it's what every mainstream library defaults to.
- Reach for v7 for new database primary keys. Its leading Unix timestamp keeps insertions roughly sequential, avoiding the index fragmentation a fully random v4 key causes at scale — a genuinely different performance profile, not just a stylistic choice.
- Use v5, not v3, for any new name-based identifier. SHA-1 is the RFC-recommended choice going forward; v3's MD5 basis exists mainly for reproducing identifiers a legacy system already generated with it.
- Paste a suspicious UUID into the decoder before assuming it's malformed. A UUID that looks unusual is often just a version you don't recognize by sight — the decoder identifies it and, for time-based versions, shows exactly when it was created.
Features
Eight Formats Solving Five Genuinely Different Problems
It's tempting to treat every UUID version as interchangeable, but they split into distinct families solving different problems. v4 is pure entropy — no information encoded, nothing derivable from it, which is exactly right when an identifier needs to reveal nothing about its origin. v1, v6 and v7 all encode time, but structure it differently: v1's field order was designed in 1996 around database indexes of that era and sorts poorly as plain text; v6 reorders those same bits so lexical sorting matches chronological order; v7 goes further with a standard Unix millisecond timestamp up front, the version most new systems reach for today. v3 and v5 are deterministic — the same namespace and name always hash to the same UUID, useful when two systems need to independently agree on an identifier without ever communicating. Nil and Max are neither random nor time-based at all, just fixed sentinel values for "empty" and "maximum" in a field typed to hold a UUID.
"GUID" and "UUID" Are the Same 128 Bits, Told Two Ways
Microsoft coined GUID before the IETF standardized UUID, and by the time RFC 4122 formalized the format, GUID had already become the entrenched name inside Windows, COM, and .NET — but the underlying value the two terms describe is identical: 128 bits, the same version and variant semantics, the same 8-4-4-4-12 grouping. The one real historical difference is display convention rather than data: classic Microsoft tooling almost always shows a GUID uppercase and wrapped in curly braces — {3F2504E0-4F89-11D3-9A0C-0305E82C3301} — while most modern web APIs and databases default to lowercase with no braces at all. That's purely presentational, which is exactly why the format switches here are independent toggles rather than one either/or choice: turning on both Uppercase and Braces reproduces the classic GUID look from the exact same underlying value a plain lowercase UUID represents.
Why Database Engineers Started Caring About UUID v7
A v4 UUID used as a primary key scatters new rows randomly across a B-tree index, since there's no relationship between one random value and the next — every insert can land anywhere in the index, which fragments it and degrades write performance as a table grows. v7 fixes this by placing a real, incrementing timestamp in the most significant bits, so consecutive UUIDs sort close together the same way auto-incrementing integers do, while still keeping enough random bits afterward to stay collision-resistant and impossible to guess sequentially. This is the specific reason PostgreSQL, MySQL and several major ORMs added native v7 support in recent versions — it keeps the operational benefits of a random, globally-unique, coordination-free identifier while fixing the index-fragmentation cost that made v4 a known scaling concern for high-write-volume tables.
v6 exists for a narrower version of the same goal: teams already running v1 in production, who need better sort behavior without switching to an entirely different bit layout their existing tooling might not recognize. Since v6 keeps the same node-and-clock-sequence structure v1 uses — just reordered for sortability — it's the more conservative migration path, while v7's simpler, purely timestamp-plus-random structure is the one actually recommended for anything being designed fresh today rather than migrated from something older.
Reading a UUID Instead of Just Generating One
A UUID's version and variant aren't hidden metadata stored somewhere else — they're literally encoded in two specific nibbles of the value itself, which means any correctly-implemented UUID can be inspected without a database lookup or an external reference. The Validate & Decode panel reads those positions directly, and for the three time-based versions, reverses the exact bit-packing used to generate them to reconstruct the original creation timestamp as a real, human-readable date. Pasting in a UUID pulled from a log file, a database row, or an API response and immediately seeing when it was created — without writing a script or consulting documentation — is a small thing that saves a genuinely common debugging detour.
From a Generated Batch to Real Data
A typical path: pick the version that matches the actual use case rather than defaulting to whatever's familiar, generate a batch sized to the immediate need, and export in whatever format the destination actually expects — SQL INSERT statements for seeding a database table directly, JSON for a fixtures file, or a plain CSV column for a spreadsheet. For a name-based UUID meant to match one another system already generates, getting the namespace exactly right matters more than anything else, since even a single-character difference in the namespace UUID produces a completely unrelated hash. Cross-checking a decoded timestamp against the Unix Timestamp Converter, or validating a UUID sitting inside a larger JSON payload with the JSON Formatter, are the two most common next steps once a batch of UUIDs is ready to use.
It's worth deciding the version once, deliberately, rather than letting it drift per developer or per feature within the same system. A codebase that mixes v1 identifiers from an older module with v4 ones from a newer feature and v7 ones from the newest service still works technically — every version is a valid 128-bit UUID regardless of how it was generated — but it makes debugging harder, since the version itself stops being a reliable signal for when or how an identifier was created. Picking one version as the team default, and reserving the others for the specific situations they're actually suited to (a v5 for cross-system deterministic IDs, say), keeps that signal meaningful instead of accidental.