UUID Generator & Inspector

Details and how to verify this yourself: Security & privacy.

The tool sits in a window that works like a desktop app: menus on the top row and the full-screen icon at its right (Esc leaves full screen). The set-up options described below are in Settings → Options…, an overlay, and the Settings menu also lists the common choices directly. To keep the options in view instead, choose View → Inline config; the page remembers that choice. Help → Keyboard shortcuts… lists the keys.

Generating.

1. Choose v4 (random) or v7 (time-ordered), how many (1–1000), and a format.
2. Press Generate, then Copy. Changing any option generates a fresh set.

Which version should you use?

• v4 has no structure at all: use it when you need an opaque identifier.
• v7 starts with the creation time in milliseconds, so new IDs sort after old ones. Database indexes stay compact, and you can sort by ID instead of by a timestamp column. Anyone can read the creation time from a v7 UUID.

UUIDs are identifiers, not secrets. v4 UUIDs come from a cryptographically secure generator, but they are not designed or reviewed as secrets. They are logged, put in URLs, and shown in UIs as a matter of course, and a v7 UUID is partly predictable. Never use a UUID as a password, API key, session token, password-reset token or unguessable “secret link”. Use a dedicated random token of at least 128 bits for those.

Inspecting. Paste any UUID to see:

• its version and variant;
• whether it is the Nil or Max UUID;
• the timestamp of v1, v6 and v7;
• the clock sequence and node of v1 and v6;
• the same UUID in every format.

Standard. RFC 9562 (May 2024), which obsoletes RFC 4122.

Accepted input formats (case-insensitive, surrounding whitespace ignored):

Any other shape is rejected with the reason: the first non-hex character and its position, the number of hex digits found, or misplaced hyphens. Output always includes the canonical form, which is lowercase (RFC 9562 §4).

Variant (the top bits of octet 8, RFC 9562 §4.1):

The version (top 4 bits of octet 6) is reported only for the RFC 9562 variant. The Nil UUID (all zeros, §5.9) and the Max UUID (all ones, §5.10) are identified as such and have no version.

Fields decoded per version.

Timestamps.

• Units: v1 and v6 timestamps are converted with the Gregorian-to-Unix offset 122,192,928,000,000,000 × 100 ns.
• isoExact has 7 fractional digits, which is exact to 100 ns.
• iso and unixMs are floored to the millisecond.
• Node: for v1/v6, nodeIsRandom is true when the multicast bit of the node is set (§6.10). Otherwise the node may be the generating machine’s MAC address.

Test vectors. The implementation is tested against RFC 9562 Appendix A:

Generation.

• v4: crypto.randomUUID(), which gives 122 random bits.
• v7: layout unix_ts_ms (48) ‖ ver (4) ‖ rand_a (12) ‖ var (2) ‖ rand_b (62). Monotonicity follows §6.2 Method 1, a fixed-length dedicated counter:
  • The counter is 42 bits: all 12 bits of rand_a plus the leftmost 30 bits of rand_b.
  • On each new millisecond it is seeded with random bits, with its top bit cleared as a rollover guard. Within the same millisecond it increases by 1.
  • The last 32 bits of rand_b are fresh random bits for every UUID.
  • If the clock stands still or moves backwards during a batch, the previous timestamp is reused. A counter overflow (2⁴¹ UUIDs in one millisecond) would advance the timestamp by 1 ms.
  • So every batch is strictly increasing, both as bytes and as strings.
  • Monotonicity is guaranteed within one batch, not across separate requests.
• Randomness: the Web Crypto CSPRNG (crypto.getRandomValues).

API.

• Count: count is 1–1000.
• Formats: format is one of the five above.
• Not idempotent: uuid_generate returns new values on every call.