JPKCom DB

UUID Generator — Tips & Tricks

Strategy and pitfalls around UUIDs: when v4 versus v7, collision safety, v5 determinism, secure randomness, NIL as a null value, and combining tools.

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, and described in the tab as "Best for most use cases" for good reason. 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) carries a leading timestamp; new values append to the end of the index. That is friendlier to indexes and makes UUIDs roughly sortable by creation time.

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. Even so, v7 delivers the same time-sortability in a more modern, simpler way. Reach for v1 mainly 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.
  • Note: the tool offers v5 (SHA-1), but not v3 (MD5). For name-based UUIDs, v5 is the recommended choice anyway.

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 is unique; duplicate 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 1000) and copy the whole block — one UUID per line. That saves repeated clicking and drops straight into SQL INSERT lists, seed scripts, or fixture files. v5 deliberately has no count selector, because the same input would always produce the same value anyway.

The NIL UUID as a deliberate null value

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. It sits in the card footer ready to copy. The tool offers no MAX UUID, so don't count on one.

Check the format before passing it on

The output is always the canonical format: lowercase, hyphenated, 8-4-4-4-12. Some systems expect uppercase or braces ({…}, especially in the Microsoft/GUID world). The tool doesn't convert that — but the result field is editable, and for larger quantities you reformat afterwards (e.g. with your editor's find-and-replace). Don't expect built-in format options here.

Everything stays in the browser

The UUID Generator makes no server call — names, namespaces, and generated UUIDs never leave your browser. So you can safely feed it business names (e.g. internal identifiers) for v5. The only requirement is an HTTPS context, because it uses 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 derivation behind v5.
  • 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.