How to use UUID Generator (v4 / v7)
What it does & when you need it
You need a unique identifier — a primary key for a new row, a correlation ID to
trace a request across services, an idempotency key for a payment retry — and
you want it now, without wiring up a library or hitting a database sequence.
This tool generates RFC 9562 UUIDs on demand: version 4 (fully random) for
the classic "just give me something unique" case, and version 7
(time-ordered) when you want IDs that also sort by when they were created. You
pick the version and how many you want, and it emits them as canonical
lowercase 8-4-4-4-12 strings, one per line, ready to paste.
Everything runs in your browser. The random bytes come from your device's
crypto.getRandomValues, the same cryptographically-secure source your
runtime uses, so no identifier is ever generated on or sent to a server.
How to use
- Choose v4 · random or v7 · time-ordered in the toolbar. v4 is the safe default; pick v7 if these IDs will become database keys.
- Set Count (1–500) for how many you need in one batch.
- Press Generate (or
Ctrl/Cmd+Enter) — the UUIDs appear in the output buffer. Toggle Uppercase or turn Hyphens off to match a specific format (for example, a compact 32-character key). - Use Copy to grab the whole list, Clear to empty it, or Sample to drop in five fresh v4 UUIDs as a starting point.
Things worth knowing
v4 versus v7 is a real database decision. A v4 UUID is 122 bits of randomness, so consecutive values are scattered all over the keyspace. As a primary key that means every insert lands in a random spot of a B-tree index, fragmenting pages and hurting write throughput on large tables. v7 fixes this by putting a 48-bit Unix-millisecond timestamp at the front, so newly created IDs are close together and append near the end of the index — the same property that makes auto-increment keys fast, but without a central counter. If you are choosing keys for Postgres or MySQL, v7 usually indexes far better; if you just need an opaque token, v4 is fine.
Not every bit is random — some are fixed by the spec. The 13th hex digit is
the version nibble: it is literally 4 in a v4 UUID and 7 in a v7 one. The
17th hex digit is the variant and is always one of 8, 9, a, or b
(binary 10xx). So ...-4a1b-8f... is well-formed while ...-3a1b-8f... is
not a v4 UUID at all. If you are validating IDs, check those two positions, not
just the overall shape.
Collisions are astronomically unlikely, but not magic. Because v4 draws from
2^122 possibilities, the birthday bound says you would need on the order of a
billion UUIDs before there is even a 50% chance of any two colliding. In
practice you will never hit that — but the guarantee rests entirely on good
randomness, which is why this tool uses a CSPRNG rather than Math.random().
v7 deliberately replaced the old time-based v1. Version 1 also encoded a timestamp, but it mixed in the host's MAC address and a clock sequence, which leaked the machine's hardware identity and its wall-clock into every ID. v7 keeps the useful part — time ordering — and fills the remaining ~74 bits with random data instead, so it sorts chronologically without revealing anything about where it was minted.
If you are generating secrets rather than identifiers, reach for the Password Generator instead, since UUIDs are predictable in structure. To fingerprint a payload rather than label it, use the Hash Generator, and if you want to read the millisecond timestamp back out of a v7 UUID, the Timestamp Converter will turn those first 48 bits into a human date.