One click, one version 4 UUID from crypto.randomUUID() — the browser's cryptographically secure generator, not Math.random — with the last five kept on screen so you can click any previous one to copy it back.
Anatomy of a v4 UUID
Take a real output from this tool: 2b4b7231-a69f-44e5-8f8c-86198ebc6404. That is 36 characters — 32 hex digits in an 8-4-4-4-12 grouping. RFC 4122 pins down six of the 128 bits: the 13th hex digit is always 4 (the version), and the 17th is always 8, 9, a, or b (the variant, whose top two bits are 10). In the sample, those are the 4 opening the third group and the 8 opening the fourth. The remaining 122 bits are random, giving 2^122 — about 5.3 x 10^36 — possible values. If a string fails either of those two positional checks, it is not a well-formed v4 UUID no matter how random it looks.
Collision odds, and the caveat that actually matters
By the birthday bound you would need roughly 2.7 x 10^18 UUIDs before hitting a 50% chance of any collision — at a million UUIDs per second, continuously, that is about 86,000 years. Deduplication logic for v4 UUIDs is wasted code. The realistic drawback is different: v4 is pure randomness, so consecutive IDs land nowhere near each other, and as clustered primary keys they fragment B-tree indexes and inflate write amplification at scale. If you need IDs that sort by creation time, that is UUIDv7's territory, which this generator does not produce.
Questions people ask
Can anyone work out when or where one of these was generated?
No. Version 1 UUIDs embed a timestamp and historically a MAC address; version 4 embeds nothing but the version and variant bits. The other 122 bits are random output with no structure to reverse.
Are these safe to use as secret tokens, like password-reset links?
The entropy is fine — 122 CSPRNG bits is more than a strong password. The problem is handling: UUIDs read as identifiers, so they end up in URLs, logs, and analytics where secrets should never sit. For anything that grants access, generate a dedicated secret with the password generator and keep it out of GET parameters.
When you need a secret rather than an identifier, use the password generator; when you need to embed or verify claims alongside an ID, that is what the JWT decoder is for.