SimplyCalculated.org

UUID Generator

Generate cryptographically random version 4 UUIDs (RFC 4122) in batches of 1 to 25, entirely in your browser — no server, no tracking, nothing uploaded.

100% private: everything is processed in your browser's memory — nothing you enter is uploaded to a server, logged, or stored.

UUID Generator

Version 4 UUIDs from the browser's cryptographically secure random number generator — no server involved, nothing tracked. Good for database keys, test fixtures, and any ID that must be unpredictable.

What Is a UUID?

A UUID — Universally Unique Identifier — is a 128-bit value designed to be unique across every system that ever generates one, without any central coordination. It looks like this: 6a980b22-aeef-42d2-b8ea-8d36d84ecdec, thirty-two hex digits broken into five groups by hyphens. The idea is powerful: instead of asking a database for the next number, any machine can mint an identifier at any moment and be confident no other machine anywhere has minted the same one. That property is what makes UUIDs the default choice for IDs in distributed systems, offline-first apps, and databases that merge data from many sources.

The format is standardized by RFC 4122, which defines both the textual representation and several "versions" that differ in how the bits are produced. The version number lives in the first digit of the third group: a v4 UUID always has a 4 there, a v1 UUID a 1, and so on. The first digit of the fourth group carries the variant marker (8, 9, a, or b), which tells parsers how the rest of the value is structured.

Why Use UUIDs Instead of Auto-Increment IDs?

  • Distributed generation: any client, app, or server can create IDs offline — no round trip to a central sequence, no contention, no "next id" bottleneck.
  • Merging: databases that sync or import from multiple sources never have to renumber records, because collisions are effectively impossible.
  • Security by obscurity (mild): UUIDs in URLs do not leak row counts the way sequential IDs do, and they cannot be enumerated by guessing the next number.
  • Pre-creation: you can create records (or references to them) before the database exists, and swap them in later.
  • Deduplication: the same content generated on two devices produces different IDs, so conflicting writes are easy to distinguish.

The Anatomy of a v4 UUID

Every v4 UUID is 16 bytes with exactly two fixed nibbles:

Field Bytes Purpose
time_low0–3Random in v4
time_mid4–5Random in v4
time_hi + version6–7Random, with the version nibble forced to 4
variant + node8–15Random, with the variant bits forced to 10xx

The names come from the original time-based design (v1); in v4 those fields are just random bytes, but the layout is kept identical so every UUID version parses the same way.

How This Tool Generates a UUID, Step by Step

  1. Fetch 16 random bytes from crypto.getRandomValues.
  2. Clear the top four bits of byte 6 and set them to 0100 — the version-4 marker.
  3. Clear the top two bits of byte 8 and set them to 10 — the RFC 4122 variant marker.
  4. Format the bytes as lowercase hex and insert the four hyphens at positions 8, 13, 18, and 23.

Of the 128 bits, 122 are random and 6 are fixed markers — which is why the collision math below talks about 122 bits, not 128.

UUID Versions at a Glance

Version Source of bits Use
v1Timestamp + MAC addressLegacy; leaks creation time and hardware identity
v3 / v5Hash of a namespace + name (MD5 / SHA-1)Same input always yields the same UUID
v4RandomThe default choice for new IDs — this tool
v7Timestamp + randomTime-sortable, friendlier to database indexes

UUIDs in the Real World

Once you know what to look for, UUIDs are everywhere. Databases from PostgreSQL (native uuid type) to MySQL and SQL Server store them as primary keys; distributed databases like Cassandra and CockroachDB generate them on the node where a row is created; mobile apps mint them offline and sync later; message queues use them as idempotency keys so a retried event is never applied twice; and every third-party API you call returns them in its JSON. They also appear in places you would not expect: image libraries give every asset a UUID, A/B testing tools use them to tag sessions, and log aggregators correlate events across services by a shared request UUID. That breadth is the whole point — one format that every system can produce and every system can parse, with no registry, no central server, and no coordination.

A Concrete Walkthrough

It helps to see the fixed nibbles land in a real value. Take the example UUID 6a980b22-aeef-42d2-b8ea-8d36d84ecdec. The first group (6a980b22) and the second (aeef) are raw random bytes. The third group starts with 4 — the version marker, set after generation. The fourth group starts with b — a valid variant digit (8, 9, a, or b). Everything after those markers is again raw random data. In binary, byte 6 was rewritten from ???????? to 0100???? and byte 8 from ???????? to 10??????, and then the whole thing was rendered as hex. That is the entire algorithm — 16 random bytes, two fixed markers, text formatting. The elegance is that such a simple recipe yields an identifier that is unique at planetary scale.

The Collision Math in Plain Terms

The birthday problem says random collisions become likely once you have roughly the square root of the space — about 2^61 UUIDs for the 2^122 random space. To put that in scale: if every person on Earth generated one million UUIDs per second, it would still take longer than the age of the universe before a collision became probable. For any system a human will operate, collisions are not a risk to design around; they are a curiosity of the math. The far more common failure is generation bugs — reusing a seed, copying a cached value, or accidentally truncating the string. This tool avoids that class of bug by generating fresh from the OS entropy source on every click.

Troubleshooting & Practical Tips

UUIDs Are Not Sortable

v4 UUIDs are random, so ordering rows by them is arbitrary and database indexes on them fragment under heavy writes. If insertion order matters for your workload, prefer a time-ordered scheme (v7 or a plain timestamp) for the primary key.

Always Normalize Case Before Comparing

Uppercase and lowercase UUIDs are equal values but different strings. Pick one case at the storage layer — lowercase is the canonical form — and normalize on write.

UUIDs and Privacy

Version 1 UUIDs embed the generating machine's MAC address and creation time — a privacy leak, and why v1 fell out of favor. Version 4 embeds nothing: no time, no machine, no input. If a system asks for an identifier that must not correlate devices, v4 is the right answer.

Keep the Hyphens

A bare 32-hex-digit string is a valid UUID in many parsers, but stripping hyphens in one place and not another causes silent mismatches. Store and compare UUIDs in their canonical hyphenated form.

Frequently Asked Questions

What are the odds of two UUIDs colliding?
Effectively zero. A version 4 UUID has 122 random bits, and the classic birthday-problem math says you would need around 2^61 UUIDs — about 2.3 quintillion, a number with 19 digits — before the collision probability reached 50%. For everyday volumes (millions of rows, thousands of IDs a day), a collision is so unlikely that systems simply never plan for one. If you ever do hit one, it is far more likely a bug in the generation code than in the random number generator.
Is the random number generator really random?
Yes — this tool uses crypto.getRandomValues, the browser's cryptographically secure random number generator, the same source browsers use for TLS keys and session tokens. It is seeded from OS-level entropy and is unpredictable in both directions: you cannot guess the next UUID, and you cannot infer anything about the generator from a past one. Math.random is never used.
Should I use UUID v4 or the newer v7?
For most applications, either works, and the trade-off is simple. v4 (this tool) is completely random, which makes it ideal for IDs that must be unguessable or that are generated offline on many devices. v7 embeds a timestamp, so IDs sort chronologically — that makes database index insertion faster under very high write rates. If you are building a high-volume database table today, v7 is often the better primary key; if you are generating identifiers for anything else, v4 is the safe, boring choice.
Can I use a UUID as a password or secret token?
As a token, sometimes: a v4 UUID's 122 random bits are in the same ballpark as a 20-character random password, so it works fine for unguessable one-time links or confirmation codes. But do not store UUIDs used as secrets in a way that leaks them, and do not use UUIDs at all as passwords people type — the hyphens and fixed structure make them awkward and they are not memorable. For passwords, use a dedicated password manager; for tokens, treat them like any other credential.
What do the "4" and the "8/9/a/b" in the third and fourth groups mean?
They are fixed marker nibbles, not random data. The 4 at the start of the third group is the version number, set by RFC 4122 to 4 for the random variant. The 8, 9, a, or b at the start of the fourth group is the variant marker — it tells parsers which UUID flavor they are looking at. Every v4 UUID has exactly this pattern, which is also how this page's validator can check a UUID at a glance.
Are uppercase UUIDs valid?
Yes. The format is case-insensitive: 6A980B22-AEEF-42D2-B8EA-8D36D84ECDEC and the lowercase version are the same UUID. The canonical form is lowercase (RFC 4122 recommends it), so this tool generates lowercase, and any system that stores UUIDs should normalize them to one case before comparing.
Is my generated UUID sent anywhere?
No. Generation uses only crypto.getRandomValues in your browser — no network request happens, nothing is logged, and every click produces a fresh, unpredictable ID with no server involvement.

Formula last verified August 22, 2026 against our published methodology .