What it does
It makes 1–1,000 UUID v4 (random), UUID v7 (time-ordered), ULID or random tokens at a time. All randomness comes from the browser's crypto.getRandomValues; tokens discard the leftover byte values so no character comes up more often than another. A pasted UUID is read for version and variant, and v1, v6, v7 and ULID values have their embedded time decoded.
Examples
| Value | Decoded |
|---|---|
017F22E2-79B0-7CC3-98C4-DC0C0C07398F | v7 · RFC 9562 variant · 2022-02-22T19:22:22.000Z (RFC 9562 Appendix A.6) |
C232AB00-9414-11EC-B3C8-9F6BDECED846 | v1 · 2022-02-22T19:22:22.0000000Z · clock sequence 13256 (Appendix A.1) |
919108f7-52d1-4320-9bac-f847db4148a8 | v4 · no time |
00000000-0000-0000-C000-000000000046 | Microsoft GUID variant — the version field has no defined meaning |
01ARZ3NDEKTSV4RRFFQ69G5FAV | ULID · 2016-07-30T23:54:10.259Z |
8ZZZZZZZZZZZZZZZZZZZZZZZZZ | cannot read — a first character above 7 overflows the 48-bit time |
Which one to use
- UUID v4: 122 random bits. For identifiers that need no order.
- UUID v7: the first 48 bits are Unix time in milliseconds, so string order = creation order. Good for database keys where sorting and indexing matter. When several are made in the same millisecond, this tool uses a 12-bit counter (RFC 9562 §6.2, method 1) so a batch keeps its order.
- ULID: 48-bit time + 80 random bits written as 26 Crockford Base32 characters — shorter, no hyphens. Within one millisecond the random part is incremented by 1 (ULID spec).
- Random token: values people paste, such as API keys, invite codes or temporary passwords. Length × log₂(set size) is the number of bits of possible values (e.g. 32 Base64url characters = 192 bits).
How it was checked
Before publishing, all of these matched: 200 each of generated v4, v7 and ULID checked with python3 uuid and an independent decoder written from the ULID spec (version and variant bits, v7/ULID time within the generation window, a batch sorting in string order), length and character set of 200 tokens, ordering with a fake clock that stalls and goes backwards, and 24 known values (the v1, v3, v4, v5, v6, v7 and v8 examples from RFC 9562, nil and max, other variants, v1/v3/v5 made by python, the ULID example, minimum and maximum) compared with python's results. The times were also compared directly with the time the RFC states (2022-02-22 14:22:22 GMT-05:00). The quality of the randomness itself is the browser's CSPRNG; this tool makes no separate claim about it.
Common mistakes
- Forgetting that v7 and ULID contain a timestamp — anyone can see when the value was made. Use v4 if creation time must stay hidden.
- Using a UUID as a secret — UUIDs are identifiers. For secrets like password-reset links, use a long random token.
- Typing
I,LorOinto a ULID — Crockford Base32 does not use them. This tool reports an error instead of guessing1or0.
FAQ
How do I make these on the command line?
On Linux, cat /proc/sys/kernel/random/uuid or uuidgen -r makes a v4. Recent util-linux has uuidgen -7 (--time-v7) for v7 — older distributions lack the option, so check uuidgen --help. For tokens, openssl rand -hex 16 or openssl rand -base64 24 are common.
Can two values collide?
A v4 has 122 random bits, so the chance is tiny but not zero. Keep a unique constraint in your database.
Are generated values kept on a server?
No. They are made in this browser and sent nowhere. They are not written to the address bar or browser storage and are not passed to this site's analytics or ads. Details are in the privacy notice.