UUID / GUID Generator
Cryptographically secure identifiers generated locally on your device.
Settings
About UUID / GUID Generator
A Universally Unique Identifier (UUID) is a 128-bit number used to identify information in computer systems. Version 4 UUIDs rely on cryptographic randomness, making duplicates virtually impossible. All calculations run client-side using Web Crypto APIs.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Producing an identifier for a record that must be unique without coordinating with a server.
- Generating a correlation id to trace one request across several services.
- Creating keys for a test fixture that cannot collide.
- Producing an idempotency key for a retried API call.
- Generating an identifier before a row exists so the client can reference it.
How it works in practice
A worked example
Two services have to agree on the identifier for the same external record, and neither one can ask the other what it picked.
Version: v5 — name-based, SHA-1 Namespace: URL (6ba7b811-9dad-11d1-80b4-00c04fd430c8) Name: invoices/2026/AC-4471
45f140e7-5f1c-5ecd-8a21-67f42c1d7afb same name under the DNS namespace instead: dd620b00-919d-560e-a9a5-02d77d806f5f
That first value is not a draw, it is a function. Version 5 hashes the namespace together with the name using SHA-1 and keeps the leading 128 bits, overwriting six of them to record the version and the layout — which is why the third group begins with a 5 and the fourth with an 8. Run it again on another machine, in another language, next year, and the same string comes back. Change nothing but the namespace and every bit moves, which is what a namespace is for: one name under two of them is two unrelated identifiers.
The edge case that catches people
Determinism cuts both ways, because an identifier anyone can compute is an identifier anyone can guess. Derive one from a customer's email address under a published namespace and knowing the address is enough to reproduce the value, at which point a URL containing it has stopped being unguessable. That is not a defect in version 5 — it is the same property that lets two services agree without talking to each other — but it does mean a derived identifier is a name and never a secret. Where the value has to be unpredictable, version 4 is the one to reach for.
When not to use this tool
Version 7 carries a millisecond timestamp in its leading bits, in the clear. Anyone holding one can read off when the row was created, which is harmless inside a database and a small disclosure in a public URL, where it hands over signup order and account age without anyone needing to ask. Version 4 is the answer there. And when a human will read the thing aloud or retype it, thirty-six characters is simply the wrong shape: a shorter scheme, or a sequence hidden behind an opaque public slug, costs far less to live with.
Frequently Asked Questions
- What is a UUID?
- A Universally Unique Identifier is a 128-bit number formatted as 8-4-4-4-12 hex digits (e.g. 550e8400-e29b-41d4-a716-446655440000). They can be generated independently on any machine with an astronomically low collision probability.
- What's the difference between UUID v4 and v7?
- v4 is entirely random — ideal for most use cases. v7 embeds a millisecond timestamp in the top bits, making it time-ordered. v7 is better for database primary keys as it maintains insertion order and improves B-tree index performance.
- Are UUIDs guaranteed to be unique?
- Not mathematically guaranteed, but the collision probability for v4 is roughly 1 in 10^36 per pair — effectively impossible in practice. v1 and v7 use time-based components that further reduce collision risk.
- Should I use UUIDs or auto-increment IDs in my database?
- UUIDs are better when you generate IDs client-side (before insert), merge multiple data sources, or need to avoid exposing sequential record counts. Auto-increment IDs are smaller, faster to index, and simpler for single-database apps.
- How should I store UUIDs in a database?
- Use the native UUID type in PostgreSQL, or BINARY(16) in MySQL for the best performance. VARCHAR(36) works but wastes storage and slows index lookups compared to a native 16-byte binary type.
- What are the version and variant bits?
- Six bits of the 128 are fixed to identify the version and layout, which is why a v4 UUID has only 122 random bits and always shows a `4` at one position. Generating 128 random bits produces something that is not a valid UUID.
- Why is the nil UUID a bad default?
- Because all-zeros is a legal UUID, so a field defaulting to it looks populated. A missing value should be null; using the nil UUID means every consumer has to know to treat one specific valid value as absent.
Common errors and gotchas
- Using a version 4 UUID as a primary key and expecting index locality, which random values destroy.
- Assuming an unguessable id is an access control, when URLs leak into logs and referrers.
- Storing a UUID as a 36-character string where a 16-byte column would be far smaller.
- Expecting time ordering from version 4, which is purely random.
- Comparing UUIDs as strings across systems that differ on case or on hyphenation.