UUID Generator

How to Use

Enter how many UUIDs you want, up to 100 at a time, and click Generate. Each one is a random version 4 UUID created using your browser's built-in cryptographically secure random number generator, printed one per line in the output box. Click Copy All to copy the entire list to your clipboard in one step, ready to paste into a database seed script, a config file, or a test fixture. The tool regenerates a fresh batch automatically when the page first loads, so you always land on a working example instead of an empty box.

Anatomy of a UUID

A UUID is a 128-bit number, almost always written as 32 hexadecimal digits arranged in five groups separated by hyphens, in the pattern 8-4-4-4-12, for example 3fa85f64-5717-4562-b3fc-2c963f66afa6. Those hyphens carry no meaning of their own, they exist purely to make a long string of hex digits easier to read and copy correctly. Two of the 128 bits are not random at all. The first character of the third group is fixed to encode the UUID's version, and the first one or two bits of the fourth group encode the "variant," a flag that identifies which UUID specification the value follows. For a version 4 UUID specifically, that means the third group always starts with the digit 4, and the fourth group always starts with 8, 9, a, or b. Strip out those fixed bits and you're left with 122 truly random bits, which is where all of a v4 UUID's uniqueness comes from.

UUID Versions Compared

The UUID specification defines several different ways to generate the same 128-bit shape, and picking the right one matters more than it looks. Version 1 builds a UUID from the current timestamp combined with the network card address of the generating machine, which makes early and late UUIDs sortable by creation time, but also leaks which physical device created each one, a privacy concern in some contexts. Version 3 and version 5 are deterministic rather than random: you feed in a "namespace" UUID plus a name string, and the tool hashes them together with MD5 (v3) or SHA-1 (v5) to produce the same UUID every time for the same input, useful when you need a stable ID derived from something like a URL or an email address rather than a random one. Version 4, what this tool generates, drops all of that and uses 122 bits of pure randomness, trading sortability and determinism for maximum simplicity and no embedded information whatsoever. A newer version 7 has gained popularity for database keys specifically, it puts a millisecond-precision timestamp in the leading bits and fills the rest with randomness, giving you IDs that sort chronologically like an auto-incrementing integer while still being effectively impossible to guess or enumerate.

Why Random UUIDs Practically Never Collide

It can feel unsettling to trust a random string with no central registry to stay unique forever, so it helps to see the actual numbers. A version 4 UUID has 2^122 possible values, which works out to roughly 5.3 x 10^36, an almost incomprehensibly large number. The relevant question isn't "how many UUIDs exist" but "how many would I need to generate before two happen to match," a classic birthday-paradox calculation. Working through that math shows you would need to generate about 2.7 x 10^18 UUIDs, 2.7 quintillion of them, before there's even a 50% chance that any two collide. Generating one billion UUIDs every single second, nonstop, it would take roughly 86 years to reach that point. For virtually every real application, from tagging log entries to assigning database keys, the odds of an accidental collision are close enough to zero to ignore entirely.

Common Use Cases

UUIDs show up anywhere two systems need to agree on a unique identifier without talking to each other first. Database primary keys are the most common case, letting multiple application servers or microservices insert new rows without a shared auto-increment counter creating a bottleneck or a single point of failure. API idempotency keys use a UUID generated once by the client and sent with a request, so if the network drops the response and the client retries, the server can recognize the duplicate request by its UUID and avoid processing the same payment or order twice. Session tokens, request-tracing IDs that follow a single request across a chain of microservices, generated file names that need to avoid collisions in shared storage, and test-fixture data in QA environments are all common places a fresh batch of UUIDs comes in handy, which is exactly why this tool lets you generate up to 100 at once instead of just one.

UUIDs vs Auto-Incrementing IDs

An auto-incrementing integer primary key (1, 2, 3, and so on) is compact, sorts naturally, and indexes efficiently because new rows always append to the end of the index. Its downside is that it requires a single authority, usually the database itself, to hand out the next number, which becomes a coordination problem the moment you have multiple database instances or offline clients that need to create records before they can reach a server. UUIDs flip that tradeoff: any client, anywhere, can generate a globally unique ID with zero coordination and zero risk of collision, but at the cost of a larger storage footprint (16 bytes minimum, 36 bytes if stored as text) and worse index locality for purely random v4 values, since new rows get inserted at random points throughout the index rather than appended at the end. Systems that need distributed ID generation but still want the indexing benefits of sequential keys increasingly reach for time-ordered UUID v7 instead of v4, or use a hybrid like storing a v4 UUID as the public-facing identifier alongside an internal auto-increment integer for indexing.

Common Mistakes

Storing UUIDs as a 36-character text string instead of a native 16-byte binary or UUID column type is the most frequent inefficiency, it roughly doubles storage and index size for no benefit, most databases (PostgreSQL, MySQL 8+, SQL Server) have a dedicated binary UUID type for exactly this reason. Assuming a v4 UUID is sortable by creation time is another common mistake, since v4 is pure randomness, two UUIDs generated a millisecond apart can sort in either order, use v1 or v7 if chronological ordering matters. Treating a UUID as secret or unguessable in the way a password is meant to be is risky in specific cases, since if an attacker can already see one valid UUID (in a URL, for instance) that alone doesn't help them guess another, but UUIDs generated with a weak or non-cryptographic random source (some older libraries, or hand-rolled v4 implementations) can be far more predictable than the 122-bit theoretical randomness suggests, which is why this tool relies on the browser's cryptographically secure crypto.randomUUID() rather than Math.random().

Frequently Asked Questions

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit value, usually written as 32 hex digits split into five groups, designed to be unique across systems without any central coordination. This tool generates version 4 UUIDs, which are randomly generated rather than based on a timestamp or hardware address.

How unique is a version 4 UUID really?

A version 4 UUID has 122 random bits, giving roughly 5.3 undecillion possible values. Even generating billions of UUIDs per second, the odds of a collision remain astronomically small, which is why UUIDs are trusted as unique identifiers in databases and distributed systems without checking for duplicates.

What is the difference between UUID v4 and other versions like v1 or v7?

UUID v1 is built from the current timestamp plus the generating device's network card address, which makes it sortable but leaks machine identity and creation time. UUID v3 and v5 are generated deterministically from a namespace and a name using MD5 or SHA-1, so the same input always produces the same UUID. UUID v4, the type this tool generates, is pure randomness with no embedded information at all. UUID v7, a newer format, combines a millisecond timestamp prefix with random bits so IDs sort chronologically while still being hard to guess, useful for database indexes where v4's total randomness hurts insert performance.

Can I safely use UUIDs as database primary keys?

Yes, and it is a common pattern, especially for distributed systems where multiple servers need to generate IDs without coordinating with each other. The tradeoff is that random v4 UUIDs are not sequential, so inserting them into a B-tree index causes more random page writes than an auto-incrementing integer would, which can slow down writes on very large tables. Many databases mitigate this by storing the UUID as a 16-byte binary column instead of a 36-character string, or by switching to time-ordered UUID v7 for the sorting benefits of an integer key with the collision-free benefits of a UUID.

Is this UUID generator secure, and does it send any data to a server?

The generator calls crypto.randomUUID(), a browser API backed by the operating system's cryptographically secure random number generator, the same underlying source used for TLS keys and other security-sensitive randomness. No UUID is transmitted anywhere; generation, display, and copying all happen locally in your browser tab, and nothing is logged or stored on any server.

Why do some UUIDs start with specific characters like 4 or 8?

A UUID is not entirely random. The version and variant fields are fixed bits reserved by the specification so software can tell what kind of UUID it is looking at. In a version 4 UUID, the first character of the third group is always 4, marking it as version 4, and the first character of the fourth group is always 8, 9, a, or b, marking the standard variant. Only the remaining hex digits are truly random, which is where the 122 random bits come from.