UUID v4 vs v1 vs v5: What's the Difference?

"Generate a UUID" usually just means v4 by default, and most of the time that's the right call. But the version number isn't decoration — v1 and v5 encode real information into the ID in ways v4 deliberately doesn't, and picking the wrong one can leak more than you meant to, or fail to give you the property you actually needed.

What a UUID is, underneath the version differences

Every UUID is a 128-bit value, formatted as 32 hex characters split into five groups (8-4-4-4-12). The whole point of the format is that independent systems can generate IDs without coordinating with each other and still not collide. How those 128 bits get filled in is exactly what the version number decides.

v4: random, and almost always the right default

A v4 UUID is generated from a cryptographically secure random number generator. 122 of its 128 bits are genuinely random (the other 6 are fixed to mark the version and variant), which makes the odds of two v4 UUIDs ever colliding astronomically small — negligible at any scale a real system will actually reach. Because it's pure randomness, a v4 UUID reveals nothing about when or where it was generated. This is what most systems mean when they say "UUID" without qualification, and it's what our UUID Generator produces.

v1: timestamp and machine identity, encoded directly in

A v1 UUID embeds the current timestamp and the generating machine's MAC address (or a substitute identifier) directly into the value. That's genuinely useful for one thing: v1 UUIDs sort roughly chronologically, which v4's pure randomness can never do. It's also the reason v1 fell out of favor as a default — anyone holding a v1 UUID can extract approximately when it was created and a machine-identifying value, which is a real information leak most applications never intended to expose. It still shows up in legacy systems and some databases that specifically need that time-ordering property.

v5: deterministic, not random at all

A v5 UUID is generated by hashing a namespace identifier together with a name — a URL, a domain-scoped string, anything you can supply consistently — using SHA-1. The property that matters here isn't randomness, it's the opposite: the same namespace and name always produce the exact same UUID, every time, on any machine, with zero coordination required. That's valuable when you need a stable ID derived from something you already have — turning a URL into a consistent identifier without having to look up or store a mapping anywhere.

Which one to actually use

• Default to v4 for session tokens, database primary keys, request IDs — anything where you just need a unique identifier and nothing about it should be inferable from the value itself.
• Reach for v5 when you need the same input to always deterministically produce the same UUID, without a database lookup.
• Avoid v1 unless you specifically need chronological sortability and have accepted that the ID leaks a timestamp and a machine identifier — for most applications built today, that trade-off isn't worth it.

Our UUID Generator creates random v4 UUIDs instantly in your browser, one at a time or in a batch.