Generate one or many RFC 4122 UUIDs (v4 or v7). Uses the browser’s crypto.randomUUID and crypto.getRandomValues APIs for cryptographic-grade entropy. Pick a version, pick a count, click Generate, copy the whole list with one click.
v4 vs v7
v4 — fully random. 122 bits of entropy (plus 4 bits for the version nibble and 2 for the variant). No structure, no timestamp, no machine identifier. The only standard UUID version used in most applications, especially for anonymous identifiers and tokens where you don’t want any ordering to leak information.
v7 — time-ordered. The first 48 bits are a millisecond Unix timestamp (big-endian), followed by 74 random bits. Sorts chronologically as a string, which makes it excellent for database primary keys because consecutive insertions hit adjacent B-tree index locations instead of scattering randomly across the index.
Both are 128 bits total, both use the same hex-with-dashes format (xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx where M is the version and N starts with 8, 9, a, or b for RFC 4122 variant).
Example: v4 output
A typical v4 UUID: 550e8400-e29b-41d4-a716-446655440000. The 4 in position 14 is the version nibble; the a in position 19 is the variant nibble. Everything else is random.
Example: v7 output
A typical v7 UUID: 018bac5c-9d00-7abc-8123-456789abcdef. The first 12 hex digits (018bac5c9d00) are the timestamp — that’s 0x018bac5c9d00 = 1,700,000,000,000 ms since epoch, which is 2023-11-14 22:13:20 UTC. The 7 in position 14 is the version; the 8 in position 19 is the variant. Remaining 74 bits are random.
Example: bulk for test fixtures
Need 50 test UUIDs for seeding a database? Set count to 50, pick v7 (so the test order matches creation order), generate, copy, paste into your fixture file. Much faster than running a generator script.
Collision probability
For v4:
- Generating 1 million UUIDs: probability of any collision ≈ 2.7 × 10⁻²⁵
- Generating 1 billion UUIDs: ≈ 2.7 × 10⁻¹⁹
- 50% chance of collision requires: ~2.7 × 10¹⁸ UUIDs
This is the “birthday problem” applied to 122 bits: collision probability ≈ n² / 2 × 2¹²². For any realistic application, collisions don’t happen.
For v7, the timestamp prevents collisions across different milliseconds. Within the same millisecond, the 74 random bits give 2⁷⁴ ≈ 1.9 × 10²² possible values, which is more than enough for any rate of generation a browser can sustain.
Use cases
- API request IDs: v4, stored in logs for tracing
- Database primary keys: v7 for B-tree locality, v4 if ordering must not leak
- Session tokens: v4, with other precautions (HMAC signing, expiry)
- Anonymous user IDs: v4
- File upload IDs: v7 so sorting by ID gives chronological order
- Test fixture IDs: v7 so tests are deterministic-ish (same ms ≈ same order)
What this tool does not do
It doesn’t generate v1, v3, v5, or v6 UUIDs. v1 requires a MAC address (privacy concern); v3 and v5 hash a name into a UUID (different use case, needs input); v6 is a rarely-used predecessor of v7. For any of these, use a dedicated library.
It doesn’t store generated UUIDs. They appear in the page, you can copy them, but nothing persists between sessions.
It doesn’t validate UUIDs — only generates. A separate validator tool could check structural correctness.
It doesn’t parse timestamps from v7 UUIDs. If you have a v7 UUID and want to extract the embedded timestamp, parse it yourself: the first 12 hex digits (minus the dash after position 8) are the big-endian millisecond timestamp. For converting that timestamp into a human date, the Unix timestamp converter is the follow-up.