What a UUID is made of
A UUID is 128 bits written as 32 hexadecimal characters in the 8-4-4-4-12 pattern, for example 018f3a2c-9c4e-7c3b-8f1a-2b7d4e5f6a7b. The current specification is RFC 9562 (2024), which replaced RFC 4122 and added the time-ordered versions 6, 7 and 8. GUID is Microsoft’s name for the same 128-bit value.
Two positions are not random. The first character of the third group is the version digit — 4 or 7 here — and the first character of the fourth group encodes the variant, which is why RFC-compliant UUIDs almost always show 8, 9, a or b there. That is 6 bits spent on self-description, leaving 122 bits of payload in a v4.
The hyphens and lower case are presentation, not content: 32 hex characters, {braces}, urn:uuid: and upper case all describe the same 16 bytes. The inspector normalises any of those forms before decoding.
v4 or v7: pick by where the value goes
v4 is 122 bits of cryptographic randomness and nothing else. It reveals no creation time, no machine and no ordering, which makes it the right choice for anything a stranger can see: public URLs, API tokens paired with a secret, invitation codes, file names.
v7 puts a 48-bit Unix millisecond timestamp in the first 12 hex characters and fills the rest with randomness plus a counter, so values generated later sort later as plain strings. That is what makes it a good database primary key: new rows append to the right edge of a B-tree index instead of landing at random pages, which cuts page splits, index bloat and cache misses on write-heavy tables.
The trade is disclosure: a v7 tells anyone holding it when the row was created, to the millisecond, and two v7s reveal how far apart two records were made. Signup ordering, invoice volume and internal timing all leak that way, so keep v7 internal and hand out a v4 (or a separate slug) in public.
Generating a batch of v7 in the same millisecond still sorts correctly here: a monotonic counter seeded from the random bits increments within the millisecond rather than restarting, as RFC 9562 §6.2 method 1 describes.
The other versions, and why they are not here
- v1 — 60-bit timestamp in 100-nanosecond ticks since 1582-10-15 plus a node ID that was traditionally the network card’s MAC address. It leaks hardware identity, which is exactly why v7 exists.
- v3 and v5 — deterministic: the same namespace and name always give the same UUID (MD5 for v3, SHA-1 for v5). Useful for deriving a stable ID from a URL or a DNS name, useless as a random identifier.
- v6 — v1 with the timestamp fields reordered so it sorts. It exists for systems already committed to v1; new designs should use v7.
- Nil (all zeros) and Max (all f) — reserved sentinel values, handy as a placeholder or an "unset" marker in tests and fixtures.
This tool generates v4, v7, nil and max — the four you can produce correctly in a browser without a namespace argument or a hardware identity. The inspector, however, reads any version, and decodes the embedded timestamp for v1, v6 and v7.
Are collisions something to worry about?
No, and the numbers are worth internalising. With 122 random bits, you would need to generate about 2.7 × 10^18 v4 UUIDs before the chance of a single duplicate reaches 50 %, and roughly 10^14 before it reaches one in a billion. Generating a billion per second, that is millennia.
That is what makes client-side generation safe: two browsers, two servers and an offline mobile app can all mint IDs without coordinating, which is the whole point of a UUID compared with a database sequence. Values here come from crypto.getRandomValues, the platform’s cryptographic random source, not Math.random.
Formatting a batch for your code
Up to 1,000 values come out at a time, and the format switches shape them for wherever they are going: uppercase and braces for a C# Guid or a Windows registry entry, hyphens off for a 32-character column, quotes and trailing commas for a JavaScript array or a SQL VALUES list.
When you store them, prefer a native type: PostgreSQL’s uuid and SQL Server’s uniqueidentifier keep the value in 16 bytes, while char(36) spends 36 and makes every index comparison longer. MySQL has no UUID type — BINARY(16) with UUID_TO_BIN() is the equivalent, and for v1/v6 values its swap-flag argument reorders the timestamp so they sort.
Batches are generated in this tab from the browser’s own random source. There is no API behind this page and no log of what it produced, so a key or an identifier you generate here exists only in your clipboard.
Reading an unknown UUID
Paste any UUID into the inspector and it reports the version digit, the variant (RFC 4122/9562, the legacy NCS layout, Microsoft’s, or reserved) and — for versions 1, 6 and 7 — the instant it encodes, converted to a readable date. A nil or max value is named as such.
Two things it will tell you that logs usually do not: whether an identifier you were told is "random" actually carries a creation time, and whether a value came from a proper generator at all — a variant outside 8–b generally means the ID was hand-made or copied from a different scheme.