UUID Generator & Inspector

What is a UUID?

A UUID is a 128-bit identifier written as 32 hexadecimal digits in five hyphenated groups:

0195f2b8-3c41-7a9e-bf12-5d3c8a1e4b60
└──────┘ └──┘ └──┘ └──┘ └──────────┘
    8      4    4    4        12

The point of a UUID is that you can create one without asking anyone. No central server, no sequence table, no coordination between machines. Two services that have never communicated can each mint identifiers and be confident they will not collide.

Two digits in that string are not random. They are structural:

• The first character of the third group is the version. In the example above it is 7.
• The first character of the fourth group is the variant. It must be 8, 9, a or b for a standard UUID — here it is b.

That means you can read the version of any UUID by eye, from position 15. The inspector on this page does the same thing and also decodes the embedded timestamp where one exists.

The specification is RFC 9562, which replaced RFC 4122 in 2024 and added versions 6, 7 and 8. "GUID" is Microsoft's name for the same thing; the formats are interchangeable, though Microsoft tooling often wraps values in braces.

Which version should you use?

v4 is the right default. If you just need an identifier and have no other requirement, use it.

v7 is the right choice for a database primary key. The reason is index locality. When you insert v4 keys into a clustered B-tree index, each new value lands at a random position, so the database touches pages all over the tree, splits them, and fragments the index. Insert throughput drops and the index grows larger than it needs to be. v7 puts a millisecond timestamp in the leading bits, so new rows append at the end of the index exactly as an auto-increment integer would, while remaining globally unique and generatable without a round trip.

v1 is mostly legacy. Its fields are laid out with the low-order timestamp bits first, so sorting v1 strings does not sort them chronologically — that is precisely the problem v6 was created to fix. It also historically embedded the machine's MAC address, which is a genuine information leak. This tool uses the uuid library, which generates a random node ID instead, so no hardware address is exposed.

How to generate and inspect

1. Pick a version The stats row updates to show how many bits are random and whether the result sorts chronologically.
2. Set the count Up to 1,000 at a time. Each press of Generate produces an entirely new set; nothing is reused.
3. Choose the formatting Hyphens on or off, lowercase or uppercase, and optional braces for Microsoft GUID conventions.
4. Copy or download Copy the whole list to the clipboard, or download it as a plain-text file with one identifier per line.
5. Inspect an existing UUID Paste any UUID into the inspector to read its version and variant, and for v1, v6 and v7 the exact moment it was created.

How the randomness works

The random bits come from crypto.getRandomValues(), the browser's cryptographically secure random number generator, which draws from the operating system's entropy pool.

This matters because the obvious alternative is unsuitable. Math.random() is a fast pseudo-random generator seeded from a small amount of state — in V8 it is xorshift128+. Its output looks random but is predictable given enough observed values, and it is explicitly documented as unsuitable for anything security-related. Any UUID library that uses it is producing guessable identifiers.

The collision numbers, concretely

A v4 UUID has 122 random bits, giving 2¹²² — about 5.3 × 10³⁶ — possible values. Applying the birthday problem:

In practice, collisions from a properly seeded generator are not a risk worth engineering around. Collisions that do happen in the real world come from a broken generator — a poorly seeded PRNG, a virtual machine cloned along with its entropy state, or an embedded device with no entropy source at boot.

A UUID is an identifier, not a secret

This deserves its own section because the mistake is common and the consequences are real.

Unguessability is a property of v4 specifically, and even then it is a side effect rather than a guarantee. Treating a UUID as an access token goes wrong in several ways:

• v1, v6 and v7 are partly predictable by design. They embed a timestamp. If you know roughly when a record was created, you have narrowed a large part of the value.
• Identifiers leak everywhere. They appear in URLs, and therefore in browser history, server access logs, referrer headers, analytics, error reports, CDN logs and support tickets. Secrets should not be in any of those.
• There is no expiry and no revocation. A UUID means nothing on its own, so there is no mechanism to invalidate one.
• 122 bits of entropy does not make it a credential. The entropy is fine; the handling is the problem.

A share link of the form /documents/0195f2b8-... with no authorisation check is an access-control bug, not a security feature. If you need an unguessable token, generate one explicitly and treat it as a secret — the Password Generator produces high-entropy strings for that purpose, and the JWT Debugger covers signed tokens that carry claims and expiry.

Examples of format variations you will meet

RFC 9562 specifies lowercase for output and requires parsers to accept either case. So uppercase UUIDs are valid input but non-canonical output — worth knowing if you compare identifiers as strings, because a case difference makes two identical UUIDs compare unequal.

Use cases

• Seeding a test database. Generate a few hundred identifiers for fixtures without writing a script.
• Choosing a primary key strategy. Compare v4 and v7 output to see why one clusters and the other does not.
• Correlating requests across services. A trace or correlation ID generated at the edge and passed through every hop ties log lines together.
• Making an operation idempotent. A client-generated key lets the server recognise and discard a retried request.
• Naming uploaded files. Removes any chance of collision or path traversal from a user-supplied filename.
• Debugging an unfamiliar identifier. The inspector tells you whether a value from a log is v4 or v7, and if v7, exactly when it was created.

Privacy

Generation happens entirely in your browser via crypto.getRandomValues(). No identifier is transmitted, logged or stored, and none is ever reused. Usage analytics record only the version selected and a rough count band — never the generated values themselves.