How to use this calculator
What a UUID is for, and what version 4 means
A universally unique identifier is a 128-bit value designed for one job: naming things without a central registry. Databases, message queues, event systems, and test suites all use them because a value can be generated anywhere — on any machine, offline, in a script — and still be treated as unique without asking a server for the next number. Version 4 is the random variant: of the 128 bits, 122 come from a random source and 6 are fixed by the format — the version nibble (hex 4) in the third group and the variant bits (the first hex digit of the fourth group, always 8, 9, a, or b). That is why every v4 UUID shows the same tell-tale pattern, 8-4-4-4-12: 7f3a9c21-4d2e-4b8a-9c1e-2f3a4b5c6d7e. The fixed bits are not a bug; they are how a reader can tell a v4 from a time-based v1 or a name-based v3 without any extra information.
The randomness is not from a generic random function but from the platform’s cryptographically secure source, getRandomValues — the same generator your runtime uses for secure tokens and TLS session keys. That matters because identifier collisions are most likely when the random source is weak or predictable: Math.random(), the classic offender, is not designed for this job and is never used here.
Generating identifiers for fixtures and test data
The generator produces one UUID per click or a batch of up to 100 in a single action — enough for a seed-data file, a test fixture, or a set of event ids in a staging run. Output can be lowercase or uppercase (hex is case-insensitive; the choice is purely cosmetic) and hyphenated or hyphenless. Hyphenless forms are convenient when a value is embedded in a filename or a context that treats hyphens specially; hyphenated is the conventional form that matches RFC 4122 and most documentation. Because the version and variant digits are always visible, a hand-typed fake — one where someone edited a real id — is usually easy to spot: the 4 in the third group and the 8/9/a/b start of the fourth group are the first things to check.
The page validates every generated value against the format before showing it, so a batch cannot silently contain a malformed entry. For test fixtures, generate once and reuse the values; there is no need to regenerate per run, and deterministic fixtures are easier to debug than fresh values on every execution.
Using the validator on values from elsewhere
The same page validates any UUID you paste. The check is stricter than a glance at the dash pattern: it verifies the shape (8-4-4-4-12 hex groups), the version nibble (a 4 in the third group), and the RFC variant bits (8, 9, a, or b at the start of the fourth group). A string with the right dashes but the wrong version — a v1 or v3 UUID, or a value that merely looks the part — is correctly rejected. This matters more than it sounds: many systems accept any 8-4-4-4-12 string as a v4 UUID, and subtle bugs follow when a time-based id is later treated as random.
What the validator does not do is check whether a UUID exists anywhere — it cannot, and no tool can: uniqueness is probabilistic, not registered. If your system needs to know whether an id is already in use, the database is the authority, not the format check.
Uniqueness, randomness, and the honest limits
No generator can guarantee uniqueness. Version 4 provides 122 random bits, so the probability of a collision is astronomically small — roughly one in 2^61 for a batch of two billion values — but it is not zero, and the tool says so rather than promising certainty. For practical purposes the guarantee comes from the random source: with getRandomValues, consecutive values share no predictable pattern, which is the property that makes v4 useful in the first place.
One distinction worth keeping straight: a UUID is an identifier, not a secret. Its structure is public, it is not designed for authenticated access, and the RFC does not treat it as a credential. If you need a value that protects access — a reset token, an API key, a password — use a dedicated secret generator instead, and store it where secrets belong.
Frequently asked questions
Why does my generated UUID always have a 4 in the third group?
That is the version field: RFC 4122 version 4 fixes the high nibble of that byte to 0100 (hex 4). Every valid v4 UUID shows this — it is not a bug, it is the format.
Are two generated UUIDs guaranteed to differ?
No generator can guarantee uniqueness — v4 provides 122 random bits, so collisions are astronomically unlikely (about 1 in 2^61 for two billion values) but not impossible. The tool uses the platform’s cryptographic randomness, which is the strongest source available in the browser.
What does the validator check?
The shape (8-4-4-4-12 hex groups), the version-4 nibble, and the RFC variant bits. A string with the right dash pattern but the wrong version — like a v1 or v3 UUID — is correctly rejected.
Can I use a v4 UUID as a password or access token?
No — treat UUIDs as identifiers, not secrets. The format is public, the value is not stored as a credential, and the RFC does not define it for authentication. Use a dedicated secret generator (like the password generator) for anything that gates access.
Are uppercase and lowercase UUIDs different values?
No. Hex digits are case-insensitive, so 7F3A9C21-… and 7f3a9c21-… are the same value. The tool normalizes output to whichever case you pick so the choice is a formatting preference, not a data difference.