What a UUID Actually Is and Why the Version Matters
You need a unique identifier for a database row, an API request, or a test fixture, and you want something you can generate right now without installing anything. This UUID generator guide explains what each version does, where it fits, and how to pick one without overthinking it. By the end you will know which version to reach for and which ones to avoid in your specific case.
A UUID is a 128-bit label written as 32 hexadecimal digits in five groups, like f47ac10b-58cc-4372-a567-0e02b2c3d479. The hyphens are formatting only; the value is the digits. The name is not a joke about universality so much as a statement of scope: the design goal is an identifier that will not collide with one generated by anyone else, anywhere, ever, without a central authority handing out numbers.
That last point is the whole reason UUIDs exist. Auto-incrementing integers require coordination. A UUID does not.
What the digits mean
Take any UUID and look at the first character of the third group. That digit encodes the version. 4 means version 4, 7 means version 7, and so on. The first character of the fourth group encodes the variant, which tells you which family of rules the identifier follows. Most UUIDs you meet today are variant 1, the RFC 4122 layout.
This matters because version determines two things you actually care about: how the value is generated, and whether it sorts in a useful order.
The trade-off nobody mentions
Random identifiers do not sort. Sequential identifiers do, but leak information. Every version is a different answer to that tension, and picking badly means either a slow index or an exposed record count. That is the entire decision.
UUID Version Differences at a Glance
Here is the short version before the detail.
- Version 1 — time plus MAC address. Sortable, but leaks hardware identity.
- Version 3 — MD5 hash of a namespace and a name. Deterministic, weak hash.
- Version 4 — pure random. The default choice for most applications.
- Version 5 — SHA-1 hash of a namespace and a name. Deterministic, stronger hash.
- Version 6 — reordered version 1. Sortable without the byte-swapping pain.
- Version 7 — Unix timestamp plus random. Sortable and modern, the current favourite for databases.
- Version 8 — custom layout. For when the standard ones do not fit.
Versions 2 and 9 exist in the specification but are rarely used in general software. If you see them in the wild, read the surrounding code before assuming anything.
How to Generate a UUID in the Browser
If you just need a value, this takes seconds.
- Open the browser-based UUID tool in any modern browser.
- Choose the version you need from the selector. Version 4 is the default and the safe choice if you are unsure.
- Set the quantity if you need a batch rather than a single value.
- Generate, then copy the output. The values are created locally in your browser and are not sent to a server.
- Paste into your code, config, or test fixture.
Two honest limitations. First, the randomness comes from your browser's cryptographic source, which is fine for identifiers but is not a substitute for a dedicated hardware entropy source. Second, nothing is stored between sessions. If you close the tab, the values are gone unless you copied them. For a generation workflow that is usually the point, but it is worth knowing before you generate five hundred values and navigate away. The wider collection of tools covers related conversion and formatting jobs if you need them in the same session.
Which UUID Version Should You Use?
Use version 4 when you need a random identifier and do not care about ordering, which covers most application code. Use version 7 when the value will be a primary key in a database that inserts frequently, because it keeps index writes near the end of the tree instead of scattering them. Use version 5 when the same input must always produce the same identifier. Use version 1 only when a legacy system demands it.
That is the decision in four sentences. The rest of this guide is the reasoning behind it.
Choosing a random UUID for application code
Version 4 draws 122 bits from a random source. The remaining six bits are fixed by the version and variant fields. The practical consequence is that collision risk is negligible for any realistic workload, and you never have to coordinate with another service to stay unique.
The cost is ordering. Because the bytes are random, two version 4 values generated a millisecond apart have no relationship in sort order. In a table with a clustered index on the identifier, that means inserts land at random positions, which fragments the index and slows writes as the table grows. For a few thousand rows you will not notice. For hundreds of millions, you will.
Generating a sortable UUID for database keys
This is the case version 7 was designed for. It puts a 48-bit Unix millisecond timestamp in the leading bytes, followed by random bits. Values created later sort later, so inserts append rather than scatter.
Version 6 solves the same problem by rearranging version 1's fields so the timestamp sorts correctly as a byte string. It preserves version 1's structure, which matters if something downstream expects that layout. If you are starting fresh, version 7 is the cleaner choice.
One caveat worth stating plainly: a sortable identifier leaks creation time. Anyone holding the value can read roughly when the row was created. If that is sensitive in your context, use version 4 and accept the index cost.
Creating a deterministic UUID from a name
Versions 3 and 5 hash a namespace UUID together with a name string. The same namespace and the same name always produce the same identifier, on any machine, in any language.
Version 5 uses SHA-1 and version 3 uses MD5. Both hashes are considered broken for security purposes, but that is not what they are doing here. Neither version is a security mechanism, and neither should be used to protect anything. They are a way to derive a stable identifier from a natural key, such as a URL or a fully qualified domain name.
If you need to reproduce an identifier across systems without storing a mapping table, this is the version to use. If you need unpredictability, it is the wrong one, because anyone who knows the namespace and the name can compute the same value.
When to reach for a custom layout
Version 8 lets you define your own bit layout inside the standard format. It is genuinely useful when you have constraints the standard versions do not satisfy, such as embedding a tenant identifier in a fixed position. It is also easy to misuse, because the sorting and uniqueness properties are now your responsibility rather than the specification's.
Reach for it only when you can articulate exactly why versions 4, 5, and 7 do not work. Most teams cannot, and that is a sign to use version 7.
Are UUIDs Really Unique?
Collisions are possible in principle and effectively impossible in practice for random versions. Version 4 has 122 random bits, so you would need to generate an astronomically large number of values before the probability of a duplicate became meaningful. For deterministic versions, uniqueness depends entirely on your inputs: the same namespace and name always collide by design, and different names produce different values unless the hash itself collides.
Frequently Asked Questions
Is a UUID the same as a GUID?
Functionally yes, in everyday use. GUID is the name Microsoft tooling popularised for the same 128-bit format, and the values are interchangeable in practice. The specification calls them UUIDs. If a system accepts a GUID, it will almost always accept a UUID.
Can I use a UUID as a database primary key?
Yes, and versions 6 and 7 make it a good idea. Random versions work too, but they fragment clustered indexes on write-heavy tables. On a small table the difference is invisible. Measure before you rewrite a schema over it.
Are version 4 UUIDs cryptographically secure?
They are generated from a cryptographic random source and are unpredictable, which is what you need for an identifier. They are not a substitute for a session token, an encryption key, or a password. Use a purpose-built mechanism for those.
What happens if two UUIDs collide?
For random versions, the practical answer is that it will not happen in your lifetime. For deterministic versions, a collision means you passed the same namespace and name twice, which is the intended behaviour rather than a fault. Handle it with an upsert if that is your design.
Does generating a UUID online send my data anywhere?
In a browser-based generator, no. The values are computed locally and are not transmitted. Check the specific page you use if that matters to you, since not every tool works the same way.
Conclusion
The version you want depends on one question: does this identifier need to sort? If yes, use version 7, or version 6 if you need version 1 compatibility. If no, use version 4 and move on. Use version 5 when the value must be reproducible from a name, and version 8 only when you can justify it. A good UUID generator makes the choice a dropdown rather than a research project, which is the point of having one in your browser.