UUID Generator — Tips & Tricks

Back to overview: UUID Generator · Open the live tool: www.jpkc.com/tools/uuid/

A UUID is generated in a moment — picking the right version is the real decision. This page collects what matters in practice. The technical groundwork is in the manual.

v4 or v7? The most important choice

For most cases v4 is enough — purely random, no side effects; the tab calls it "the usual choice when the ID does not need to sort". But as soon as the UUID serves as a database primary key, a second look pays off:

v4 (random) scatters new keys across the entire value range. With B-tree indexes (e.g. in MySQL/InnoDB) this leads to random insertion points and poorer cache locality.
v7 (time-ordered) starts with a timestamp, so new values append to the end of the index. That is friendlier to indexes. And because the tool generates v7 monotonically, even a batch from the same millisecond stays in creation order — which matters when you generate a whole block for an import and want to recover that order later by sorting on the UUID.

Rule of thumb: v7 for new database keys, v4 for everything else (tokens, correlation IDs, file names, components of API keys).

v1 is rarely needed anymore

v1 is the classic time-based variant. This tool generates the node part randomly and so reveals no MAC address (see manual) — so a common privacy objection to v1 does not apply here. Its drawback remains: v1 puts the low-order time bits first and therefore does not sort by time. If you need the Gregorian timestamp with clock sequence and node, use v6 — the same fields, but sortable; on the v6 / v1 Time-based tab, v6 is already the default. Without such requirements, v7 is the more modern and simpler choice. Reach for v1 only when an existing system or specification explicitly requires it.

v5 is deterministic — blessing and curse

v5 produces not a random but a reproducible UUID: same namespace plus same name always yields the same value. That is powerful — and has consequences:

Advantage: you can derive stable keys from existing names (domains, URLs, business keys) without storing them. Same input twice, same UUID twice.
Pitfall 1: v5 is not a secret. Anyone who knows the namespace and name can recompute the UUID. Never use v5 as an unguessable token — that is what v4 is for.
Pitfall 2: the namespace changes the result entirely. Fix one namespace per use case and keep it stable; otherwise your derivations won't collide — they will simply be incompatible.
Pitfall 3: the name counts byte for byte. A space at the edge, a tab from a copied spreadsheet cell, or different capitalization gives a different UUID. The tool deliberately trims nothing — that keeps its results in line with other implementations — and instead warns you with a yellow hint naming the line number. So normalize your names yourself beforehand (domains always in lower case, for instance).
v5 or v3? Both are deterministic; v5 hashes with SHA-1, v3 with MD5. Always use v5 for anything new, and switch to v3 (MD5) only when an existing system expects v3 values — the two versions return different UUIDs for the same input.

Collision safety — how unique is "unique"?

UUIDs don't guarantee mathematical uniqueness, but a vanishingly small collision probability. With v4, 122 bits are random — you'd have to generate many billions of UUIDs before a collision became even statistically relevant. The key to that is good randomness: this tool uses the browser's cryptographically secure generator (crypto.getRandomValues or crypto.randomUUID), not Math.random — so the values are neither predictable nor biased. v5, by contrast, is only as unique as the combination of namespace and name; identical inputs deliberately yield the same UUID.

Make the most of bulk generation

If you need many keys at once, set Number of UUIDs high (up to 10,000) and take the whole block — one UUID per line. Beyond a few hundred lines, Download as .txt is more practical than the clipboard: read the resulting uuids.txt straight into seed scripts, fixture files, or INSERT lists.

v5/v3 has no count selector, because the same input would always produce the same value anyway — instead, the Names — one per line field takes as many names as you like. Since every line yields exactly one UUID in the same order, you can paste a spreadsheet column and copy the result back next to it, row for row. Watch out for blank lines, though: they produce a UUID as well (for the empty name). That keeps the rows aligned, but don't adopt those values as real IDs.

NIL and Max UUID as deliberate special values

The NIL UUID (00000000-0000-0000-0000-000000000000) is not an "error" but a defined null value. Use it as a placeholder or default where a schema requires a UUID but "none yet" is meant — cleaner than an empty field or a made-up constant. Its counterpart is the Max UUID (ffffffff-ffff-ffff-ffff-ffffffffffff), which RFC 9562 defines as the upper limit — useful, for example, as the upper bound of a range query. Both sit in the card footer ready to copy, in whatever output format is currently selected.

Check the format before passing it on

The default is the canonical format: lowercase, hyphenated, 8-4-4-4-12. Some systems expect upper case, curly braces ({…}, especially in the Microsoft/GUID world), the urn:uuid: prefix, 32 characters without hyphens, or a compact Base64 form. You set all of that under Output format in the card footer — UUIDs you've already generated switch over instantly without being regenerated, and Copy and Download as .txt take exactly the displayed format.

Keep two things in mind:

The format is remembered. If you switched to Base64 yesterday, you get Base64 again today — check the selection before you copy values into a schema with a fixed length.
Base64url (22 characters, no padding) suits URLs and file names, but other systems won't automatically recognize it as a UUID. In databases, store the canonical form or the 16 raw bytes, and use the short form only externally.

The other way round, the Decode tab accepts every one of these spellings and shows the canonical form — handy for tracing a Base64 ID from a URL back to its UUID.

Timestamps are inside — the decoder shows them

v7, v6, and v1 UUIDs carry their creation time in plain sight. The Decode tab reads it out immediately, in UTC and in your local time. That's useful, say, for reconstructing when a record was created when there's no created_at column, or for checking the order of log entries. But it also means: anyone who sees such a UUID knows when the record came into being. For publicly visible IDs where that's nobody's business — invitation links, order or customer numbers — v4 is the better choice.

The decoder also helps with cleanup: paste a list of unknown IDs (up to 200 lines) and you'll see at once which version and variant each has — and which line isn't a valid UUID at all. If an ID shows an unusual version or variant, check its length: the decoder reads exactly 22 characters as Base64, so a truncated UUID shows up as a seemingly valid but wrong value.

Everything stays in the browser

The UUID Generator makes no server call — names, namespaces, and generated or decoded UUIDs never leave your browser. So you can safely feed it business names (internal identifiers, for example) for v5, or decode IDs from production data. The only thing stored is your chosen output format, in localStorage. v5 requires an HTTPS context, because it relies on the Web Crypto API.

Combine with other JPKCom tools

Hash generator — when you need not a 128-bit identifier but a full checksum (SHA-256, SHA-512 …) over some content; related to the SHA-1 and MD5 derivation behind v5 and v3.
Time Converter — convert the time the decoder reads out of a v7, v6, or v1 UUID into other time zones or Unix timestamps.
Password & key generator — for freely chosen random tokens and passwords beyond the rigid UUID format.
Cryptor (AES-256) — use a generated UUID as an identifier and encrypt the associated content client-side.

The full reference is in the manual, concrete walkthroughs in the examples. You can try everything in the tool.