🔐 Cryptographic randomness · runs in your browser
UUID Generator & Decoder
Generate UUID v4 (random) or v7 (sortable, timestamp-based) in bulk, then decode any UUID to extract its version, variant, and embedded timestamp. Fully client-side — UUIDs are generated using crypto.getRandomValues and never leave your browser.
✔ Crypto-secure
✔ UUIDv4 & UUIDv7
✔ Bulk & decode
✔ No signup
What this tool does
Generates and decodes RFC 9562 UUIDs entirely in your browser. UUIDs are 128-bit identifiers used in distributed systems, database primary keys, idempotency keys, session tokens, and anywhere you need a globally-unique value without a central coordinator.
Versions supported
- UUIDv7 — 48-bit Unix timestamp (milliseconds) followed by random bits. Time-sortable as a string, which makes it dramatically better than v4 as a database primary key in B-tree indexes. The recommended default in 2026.
- UUIDv4 — 122 bits of cryptographically-secure randomness. The right choice when you specifically need unpredictability and don't need sortability.
- NIL UUID — all zeros. Sentinel value for "no UUID set."
- Max UUID — all f's. Sentinel value for "upper bound."
What the decoder shows
- Version — v1 through v8, NIL, or Max.
- Variant — almost always RFC 9562 (formerly RFC 4122) variant; the decoder validates this.
- Embedded timestamp — for v1 (60-bit Gregorian) and v7 (48-bit Unix-ms), the decoder extracts and displays the creation time in your local timezone and UTC.
- Hex and byte representations — useful when debugging serialization.
Why UUIDv7 is usually the right default
UUIDv4 is fully random, which sounds like a good thing until you put millions of v4s into a database B-tree index. The randomness destroys index locality — new inserts land in random pages, page splits become common, and write throughput drops. UUIDv7 fixes this by putting a sortable timestamp prefix in the leading bits, so inserts land near each other in the index and the database's page cache behaves much better.
The tradeoff: UUIDv7 leaks the creation timestamp to anyone who has the ID. For most internal database keys this is fine (and often useful). For tokens that need to be unpredictable for security reasons, stick with v4.
Privacy and security
All generation uses window.crypto.getRandomValues — the browser's cryptographically-secure random source. UUIDs are produced in your browser and never sent anywhere. Safe to use for production database IDs, idempotency keys, session tokens, and other security-sensitive contexts.
Frequently asked questions
What's the difference between UUID v4 and UUID v7?+
UUID v4 is fully random (122 bits of randomness). UUID v7 packs a 48-bit Unix timestamp (in milliseconds) into the leading bits, followed by random data. The practical consequence: UUIDv7 values are time-sortable as strings, which makes them dramatically better as database primary keys than UUIDv4. UUIDv4 randomness destroys index locality in B-tree databases; UUIDv7 preserves insertion order. For new systems in 2026, UUIDv7 is usually the better default unless you have a specific reason to prefer pure randomness.
Are UUIDs generated by this tool cryptographically secure?+
Yes. The random bits come from window.crypto.getRandomValues, which is the browser's cryptographically-secure pseudo-random number generator (CSPRNG). The same primitive used by other security-sensitive browser APIs. UUIDs generated here are suitable for use as database IDs, session tokens, idempotency keys, and any other context where unpredictability matters.
Why use UUIDv7 over auto-incrementing integers?+
Auto-incrementing IDs leak information (you can see how many users a competitor has, you can enumerate other users' records by changing the ID in the URL) and create coordination overhead in distributed systems. UUIDs are generated independently anywhere, don't leak ordering information beyond the timestamp prefix, and are safe to expose in URLs. UUIDv7 keeps the database-friendliness of auto-increment (sortable, good index locality) while removing the coordination requirement.
Can this tool decode any UUID?+
It can identify the version of any properly-formed UUID (v1 through v8, plus NIL and Max UUIDs), and it can extract embedded timestamps from UUIDv1 and UUIDv7. UUIDv4 has no embedded timestamp because it's fully random — for v4 the decoder just confirms the version and validates the variant bits.
Is it safe to paste real UUIDs from production into this tool?+
Yes. Decoding runs entirely in your browser using JavaScript. The UUID is never sent to any server, never logged, and never stored. That said, if a UUID is treated as a secret in your system (which is unusual but happens with session tokens or signed URLs), the right answer is to rotate it after pasting rather than to avoid pasting.
What is the NIL UUID and when is it used?+
The NIL UUID is all zeros (00000000-0000-0000-0000-000000000000). It's defined by RFC 9562 as a sentinel value indicating 'no UUID set' — analogous to NULL but typed as a UUID. Useful as a default value in protobuf or other schemas where a UUID field is required. The Max UUID (all f's, ffffffff-ffff-ffff-ffff-ffffffffffff) is the symmetrical opposite, used as an upper-bound sentinel.
What UUID version should I use in a new project?+
For database primary keys, prefer UUIDv7 — sortable, good index performance, no coordination required. For anything where you specifically need unpredictability and don't need sortability (security tokens, opaque IDs in URLs that shouldn't reveal creation order), UUIDv4 is appropriate. Avoid UUIDv1 in new designs — it leaks the MAC address and creation time in a way most systems don't want.