UUID Versions Explained: v1, v3, v4, and v5

DevOkk’s UUID Generator mints them in the browser. Use it for fixtures, bulk test ids, and the occasional “I need twenty v4s for a migration.” Do not use a website as your production id factory if you already have crypto.randomUUID() in the runtime.

What a UUID is, and what the version digit means

The RFC layout reserves bits for version and variant. You do not need to memorize the bitfield. You need to read the third group: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. M is the version (1, 3, 4, 5, and newer 6/7 in later specs). N is the variant (8, 9, a, or b for RFC 4122).

UUIDs are unique with high probability (v4) or by construction (name-based), not because a central server issued them. That is why they show up as distributed primary keys. They are large. They are not sequential in v4, which matters for B-tree indexes - a database conversation, not a generator conversation.

A UUID is not encryption, not a capability token by itself, and not a hash you should store passwords in. It is an id format.

v4: the default for most apps

v4 fills most bits with random data. In browsers and current Node, crypto.randomUUID() is v4. That is what you want for:

• Primary keys when you do not need time-sortable ids
• Request and correlation ids
• Idempotency keys
• Object names in buckets when you do not want guessable sequences

Collisions are not the risk that should keep you up. Implementation bugs (defaulting to the empty UUID, copying one id into every row) are.

Do not “strengthen” a v4 by hashing it again or chopping it to 8 characters. Shortening is how you create a collision problem. If you need a shorter public id, use a separate purpose-built scheme, not a truncated UUID.

DevOkk defaults to v4 for a reason. Generate a batch, copy, paste into a fixture, leave.

v1: time and node, with a caveat

v1 combines a timestamp with a clock sequence and a node id. The original idea of the node id was a MAC address so two machines would not clash. That also means a v1 UUID can reveal when it was created and, on naive implementations, which machine.

Use v1 only if you have an explicit reason: time-sortable ids in an old system, or interoperability with something that already emits v1. If you want time-sortable ids in 2026, look at UUID v7 (Unix-time based) in a library that implements the newer RFC, rather than v1 plus a MAC.

If you generate v1 in a browser tool, assume the node id is not your laptop’s real MAC (implementations vary). Still do not publish v1s if the timestamp itself is sensitive (a medical appointment created-at leaking through an id).

v3 and v5: the same name, the same id

Name-based UUIDs take a namespace (itself a UUID) and a name (a string). Same pair → same output, every time, every machine. That is the point.

• v3 uses MD5 over namespace+name.
• v5 uses SHA-1 over namespace+name.

MD5 and SHA-1 are the wrong tools for password storage and for collision-resistant signatures. Here they are used as specified by the UUID RFCs to squeeze a name into 128 bits. Prefer v5 for new systems. Use v3 only to match an existing corpus.

Standard namespaces exist for DNS and URL (and others). example.com in the DNS namespace always yields the same v5. That is useful for:

• Stable ids derived from a natural key you already trust (a public URL, a DNS name)
• Migrating from “use the domain as the id” to a UUID column without a lookup table

It is a bad fit for ids you wanted to be unguessable. If I know you use v5(DNS, customer-email), I can compute the id. That can be a feature (idempotent imports) or a bug (enumeration).

v3/v5 are not a substitute for Hash Generator. If you need a SHA-256 of a file, hash the file. If you need a 128-bit id derived from a name, use v5.

Generating IDs in the browser

1. Open UUID Generator. Pick the version.
2. For v4 (and v1): set the count. Optional prefix/suffix/separator if you are making human-facing labels (ord_550e8400-…). The prefix is not part of the UUID spec; strip it before the database if the column is a UUID type.
3. For v3/v5: pick the DNS or URL namespace, or paste a custom namespace UUID. Enter the name. Generate. Confirm that generating twice matches.
4. Copy the list. Hyphens on or off depending on the consumer. Some systems want hex only; that is still the same 128 bits.
5. Uppercase versus lowercase: the spec treats them as equal. Pick one for a codebase and stay there.

Bulk generate for tests. Do not generate a million ids in a tab if you are seeding production - use the database or the app runtime.

What UUIDs are not

They are not sequential invoice numbers. Customers will not like 550e8400-e29b-41d4-a716-446655440000 on a receipt. Use a separate public number.

They are not proof of authenticity. Anyone can generate a v4. Authorization is a session or a signature, not “the id looked random.”

They are not a replacement for understanding hex. If you are staring at the version nibble and want a refresher on bases, see How to Convert Binary, Decimal, Hex, and Octal.

Newer versions (v6, v7, v8) exist for time-sortable and custom layouts. If your language’s standard library only offers v4, that is still the right default for most products.

Generate v4 unless you can justify another version

For a new id, generate v4 on UUID Generator unless you can write down why you need a name-based or time-based variant. For name-based, use v5 with a documented namespace.

If you only needed a hash, use Hash Generator and SHA-256. If you were about to use MD5 “because v3 uses MD5,” read MD5 vs SHA-1 vs SHA-256 and then still pick v5 for ids, not MD5 for passwords.