UUID Generator (v4 & v7)
Random UUID v4 and time-ordered UUID v7 identifiers, RFC 9562 compliant.
$ uuidgen
What is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit value written as 36 hexadecimal characters, like 3f2504e0-4f89-41d3-9a0c-0305e82c3301. UUIDs let independent systems create identifiers without coordination — no central counter, no collisions in practice. They are standardized by RFC 9562.
UUID v4 vs UUID v7
UUID v4 is fully random: 122 of its 128 bits come straight from the CSPRNG. It's the default choice when identifiers must be unpredictable — API keys' public ids, tokens in URLs, anything a user might see.
UUID v7 starts with a 48-bit Unix timestamp in milliseconds followed by 74 random bits. Because values generated later sort later, v7 keys keep B-tree indexes compact and make excellent database primary keys — inserts stay append-mostly instead of scattering across index pages, a well-known performance issue with v4 primary keys in PostgreSQL and MySQL. The trade-off: a v7 UUID reveals its creation time, so don't use it where that timestamp is sensitive.
How they're generated here
All random bits come from crypto.getRandomValues(); the version and variant bits are set per RFC 9562. Generation is entirely client-side — generate up to 50 at once and copy the whole list.
Should I use UUID v4 or v7?
Use v7 for database primary keys: it starts with a millisecond timestamp, so values sort by creation time and inserts stay append-mostly instead of scattering across B-tree index pages — the well-known performance problem with v4 primary keys in PostgreSQL and MySQL. Use v4 for anything a user can see or guess at: tokens in URLs, public identifiers. A v7 UUID reveals when it was created.
Can two UUID v4s ever collide?
In practice, no. A v4 UUID carries 122 random bits. You would need to generate about 2.7 quintillion of them before reaching a 50% chance of a single collision. If your v4s collide, the cause is a broken random source, not bad luck — which is why these come from crypto.getRandomValues() and not Math.random().
Are these RFC compliant?
Yes. Version and variant bits are set per RFC 9562 (which replaced RFC 4122 in 2024 and standardised v7). You can verify: the 13th hex digit is the version (4 or 7) and the 17th is 8, 9, a or b.
Nothing leaves your browser
- Don't take our word for it — turn off your wifi. Every generator on this site keeps working with the network disconnected. That's the whole proof, and it takes five seconds.
- Every value comes from
crypto.getRandomValues()— the CSPRNG built into your browser, neverMath.random(). - Generated secrets are never transmitted, logged or stored: no server-side generation, no cookies, no localStorage.
- Verify it yourself in the network tab: after loading, the page only talks to our self-hosted, cookie-less analytics — which counts page views and which generator type gets copied, never any value.
- Strict Content-Security-Policy; no third-party script origins.
All generators
- Base64 Secret Generator
- Password Generator
- Hex Secret Generator
- JWT Secret Generator
- Passphrase Generator
- SSH Key Generator (Ed25519)
- PIN Generator
- WireGuard Key Generator
- API Key Generator
- TOTP Secret Generator
- Django SECRET_KEY Generator
- Laravel APP_KEY Generator
- NextAuth Secret Generator
- Flask SECRET_KEY Generator
- Rails secret_key_base Generator
- Strapi APP_KEYS Generator
- ULID Generator
- Nano ID Generator