# 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. Source: https://www.jpkc.com/db/en/tools/uuid/tips/ Back to overview: [UUID Generator](https://www.jpkc.com/db/en/tools/uuid/) · Open the live tool: [www.jpkc.com/tools/uuid/](https://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](https://www.jpkc.com/db/en/tools/uuid/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](https://www.jpkc.com/db/en/tools/uuid/manual/#version-1-time-based-v1-time-based)) — 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](https://www.jpkc.com/db/en/tools/hash/)** — 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](https://www.jpkc.com/db/en/tools/generator/)** — for freely chosen random tokens and passwords beyond the rigid UUID format. - **[Cryptor (AES-256)](https://www.jpkc.com/db/en/tools/cryptor/)** — use a generated UUID as an identifier and encrypt the associated content client-side. --- The full reference is in the [manual](https://www.jpkc.com/db/en/tools/uuid/manual/), concrete walkthroughs in the [examples](https://www.jpkc.com/db/en/tools/uuid/examples/). You can try everything in the [tool](https://www.jpkc.com/tools/uuid/).