UUID Generator
Generate v4, v7, v1 or v5 UUIDs one at a time or in bulk — everything runs in your browser.
What is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit value, almost always written as 32 hex digits split into five hyphenated groups like 3fa85f64-5717-4562-b3fc-2c963f66afa6, that's designed to be generated independently by any number of computers without ever needing to check with each other to avoid collisions. That property makes UUIDs the default choice for database primary keys, distributed-system record IDs, session tokens, and file names — anywhere you need an identifier that's guaranteed unique without a central counter handing out numbers.
Worked examples
Test fixture IDs for a QA CSV import
A QA engineer needs five fake order IDs for a fixture file, formatted uppercase with no hyphens to match a legacy system's ID column.
- Version
- v4
- Count
- 5
- Format
- Uppercase, no hyphens
≈ 9B1DEB4D3B7D4BAD9BDD2B0D7B3DCB6D — five lines like this, each independently random
A stable ID for a domain name
A DNS record importer needs an identifier for "example.com" that's identical every time it's regenerated — on any machine, in any language.
- Version
- v5
- Namespace
- DNS
- Name
- example.com
= cfbff0d1-9375-5685-968c-48ce8b15ae17, exactly, every single time
How each version works
v4 — random. 122 bits come straight from a cryptographically secure random number generator (crypto.randomUUID() in the browser); the remaining 6 bits are fixed to mark the version and variant. No timestamp, no machine info — just randomness.
v7 — timestamp-ordered. The first 48 bits are the current Unix time in milliseconds, followed by 74 random bits. Because the timestamp comes first, v7 UUIDs generated later always sort after ones generated earlier — useful as database primary keys, where sequential values keep index pages from fragmenting.
v1 — timestamp + node. A 60-bit timestamp (100-nanosecond intervals since 15 Oct 1582, the Gregorian calendar's start date, for historical reasons), a random clock sequence, and a 48-bit node ID. Real MAC addresses were originally used for the node ID; browsers can't read one, so this tool fills it with random bytes and sets the "locally administered" bit, exactly as RFC 4122 allows.
v5 — namespace hash. Deterministic: it SHA-1 hashes a namespace UUID concatenated with a name string, then overwrites a few bits to mark the version and variant. Same namespace + same name = same UUID, forever.
| Version | Basis | Sortable | Best for |
|---|---|---|---|
| v4 | 122 random bits | No | General-purpose IDs, tokens, primary keys |
| v7 | Timestamp + random | Yes | Database keys, event logs, anything sorted by creation time |
| v1 | Timestamp + random node | Roughly | Legacy systems expecting RFC 4122 v1 |
| v5 | SHA-1(namespace + name) | No | Reproducible IDs derived from a URL, domain, or path |
Frequently asked questions
Which UUID version should I use by default?
UUIDv4 is the safest default for most applications — it's fully random, requires no coordination between systems, and is supported everywhere. Reach for v7 instead if the UUIDs will be primary keys in a database, since its embedded timestamp keeps new rows clustered together on disk instead of scattering random inserts across the whole index.
Does UUIDv1 leak my MAC address or device identity?
Not from this tool. The original 1990s RFC 4122 spec did allow embedding a real IEEE 802 (MAC) address in the last 48 bits of a v1 UUID, which is why v1 got a reputation for leaking hardware identity. Browsers have no way to read a MAC address anyway, so this generator follows the RFC's own fallback: those 48 bits are filled with cryptographically random bytes and the node ID's multicast bit is set to mark it as non-hardware, exactly as RFC 4122 §4.5 specifies.
What makes UUIDv5 different from v4, v7, and v1?
v4, v7, and v1 are all randomized (or partly randomized) — generate one twice and you get two different values. v5 is deterministic: it hashes a namespace UUID together with a name string using SHA-1, so the exact same namespace and name always produce the exact same UUID, on any machine, any time. That makes it useful for turning an existing identifier — a URL, a domain name, a file path — into a stable UUID without storing a lookup table.
Why can't I bulk-generate UUIDv5 values?
Because v5 is deterministic, generating a batch from one fixed namespace and name would just repeat the same UUID over and over, which isn't useful for a bulk list. Bulk generation is enabled for v4, v7, and v1 — the versions where every value is independently random. To get a batch of unique v5 UUIDs, run this tool once per distinct name, or hash each name in your own code using the same namespace + SHA-1 approach shown in "How it works" below.
Are the generated UUIDs unique — could two ever collide?
For v4 and the random portion of v7/v1, collisions are astronomically unlikely: a v4 UUID has 122 random bits, so you'd need to generate roughly 2.7 quintillion of them before a 50% chance of any collision — far beyond what any single application produces. v5 collisions can only happen if you reuse the exact same namespace and name on purpose, which is the intended, reproducible behavior rather than a flaw.
Is anything I type or generate here sent to a server?
No. Every UUID — single or bulk, all four versions — is generated in your browser using the Web Crypto API (crypto.randomUUID, crypto.getRandomValues, and crypto.subtle.digest for v5). Nothing you type into the name field or generate in bulk ever leaves your device.