Free UUID generator

A UUID (Universally Unique Identifier), also known as a GUID (Globally Unique Identifier on Windows and in .NET), is a 128-bit number used to identify information in computer systems without relying on a central authority to hand out IDs. A UUID is almost always written as 32 hexadecimal digits, split into five groups separated by hyphens, in the pattern 8-4-4-4-12, for example: f47ac10b-58cc-4372-a567-0e02b2c3d479.

The key idea behind a UUID is that it can be generated independently, on any machine, at any time, without coordinating with anyone else — and the odds of two independently generated UUIDs colliding are so small that they're treated as effectively zero in practice. That makes UUIDs the default choice for primary keys, request IDs, session tokens, file names, and distributed system identifiers where you can't rely on an auto-incrementing counter from a single database.

UUIDs are standardized by RFC 9562 (which obsoletes the older RFC 4122), published by the IETF. The standard defines several “versions” of UUID, each encoding information differently inside those 128 bits — this tool focuses on the two most useful versions for modern applications: v4 and v7, plus the special all-zero “nil” UUID.

Every UUID encodes a 4-bit “version” number in the third group, so software can tell at a glance how the ID was constructed. The version matters because it determines what information (if any) leaks from the ID, and whether IDs sort in a useful order.

There are also v3 and v5 (deterministic, generated by hashing a namespace and a name — the same input always produces the same UUID), and v2 (a rarely used DCE security variant). This tool doesn't generate those because they're either deprecated in practice or need application-specific input rather than randomness. For everyday use, the choice is almost always between v4 (fully random, unpredictable) and v7 (time-ordered, database-friendly).

Why does sortability matter so much for v7? Databases like PostgreSQL and MySQL store primary keys in a B-tree index. Inserting fully random v4 values scatters writes across the whole index, causing page splits and cache misses that get worse as the table grows. Because v7's leading bits are a timestamp, new rows are inserted at the “end” of the index in roughly chronological order — much closer to the append-friendly behavior of a traditional auto-increment integer, while still being globally unique and generateable on any node without coordination.

A version 4 UUID has 122 bits available for randomness (128 total bits, minus 4 for the version and 2 for the variant). That gives 2^122 possible values — roughly 5.3 × 10^36, or 5.3 undecillion. To put that in perspective, that's many times more than the estimated number of grains of sand on Earth, or atoms in a mole of a substance.

The relevant question isn't “how many possible UUIDs are there” though — it's “how many would I need to generate before two collide.” That's the birthday problem: with n possible values, the probability of at least one collision after generating k items is approximately 1 − e^(−k² / 2n). For a 50% chance of any collision at all, you'd need to generate roughly 1.25 × √n UUIDs — about 2.7 × 10^18 (2.7 quintillion) v4 UUIDs.

Concretely: if you generated 1 billion UUIDs every second, it would take roughly 85 years of continuous generation before you'd have even a 50% chance of a single collision. Most real applications generate a tiny fraction of that over their entire lifetime, which is why UUID collisions are treated as a non-issue in practice — you're astronomically more likely to be struck by a meteorite than to see a genuine v4 UUID collision.

UUID v7 has slightly less pure randomness (74 bits instead of 122, since 48 bits are spent on the timestamp), but that randomness resets its collision risk every millisecond rather than sharing one giant pool — within any single millisecond, you'd need to generate around ~400 million v7 UUIDs before a 50% collision chance among just that millisecond's batch. For virtually every real workload, generating thousands of IDs per millisecond is already unrealistic, so v7 remains effectively collision-free for practical purposes.

• Database primary keys. UUIDs let every service or node generate valid IDs without querying a central sequence, which is essential for distributed databases and microservices.
• API request & trace IDs. Attaching a UUID to every API request makes it possible to trace a single call across logs, services, and retries.
• Session tokens & API keys. Randomness makes v4 UUIDs hard to guess, which is why they're common as session identifiers (though dedicated secrets are preferred for anything security-critical).
• File and object storage names. S3 buckets, CDN assets, and uploaded files are often renamed to a UUID to guarantee no two uploads ever collide, regardless of the original filename.
• Software licensing & device identifiers. Product keys, install IDs, and hardware identifiers frequently use UUIDs so vendors can track activations without a central counter.
• Version control & package systems. Some build systems and package managers tag artifacts with UUIDs to avoid naming collisions across independent publishers.
• Testing & seed data. Developers generate bulk UUIDs to populate test databases, mock APIs, or fixtures with realistic-looking unique identifiers.
• Idempotency keys. Payment and messaging APIs (like Stripe) use client-generated UUIDs as idempotency keys so a retried request is recognized as a duplicate rather than processed twice.

1. Grab a single UUID. A fresh v4 UUID is generated the moment the page loads — copy it with one click, or hit Regenerate for a new one.
2. Switch versions. Use the segmented control to switch between v4 (random), v7 (time-sortable, with a timestamp breakdown shown underneath), and Nil (the all-zeros UUID used as a placeholder or “empty” value).
3. Generate in bulk. Set a quantity from 1 to 1,000 and the tool fills a monospace text box with that many UUIDs, one per line.
4. Format for your use case. Toggle Uppercase, Remove hyphens, or Quotes + commas to get UUIDs ready to paste straight into code, JSON arrays, or a SQL INSERT statement.
5. Copy or download. Use Copy all to grab the whole batch, or Download .txt to save it as a file.

Yes. Every UUID is generated locally in your browser using the Web Crypto API (crypto.getRandomValues and crypto.randomUUID), the same cryptographically secure random number generator used by browsers for encryption keys. Nothing is uploaded to a server, nothing is logged, and the tool works even offline once the page has loaded. That makes it safe to generate UUIDs for internal systems, database seeds, or anything else without worrying about the values being observed or stored elsewhere.

• Are UUID and GUID the same thing? Functionally, yes — GUID is Microsoft's name for the same 128-bit identifier format standardized as UUID. Any tool that generates one generates the other.
• Can I use a UUID as a primary key? Yes, and it's common in distributed systems. Prefer v7 over v4 for primary keys when your database supports it, since the embedded timestamp keeps index inserts sequential and avoids the write-amplification problems random v4 keys cause at scale.
• Do UUIDs need to be stored as strings? No — most databases support a native 16-byte binary UUID type (e.g. PostgreSQL's uuid column), which is smaller and faster to index than storing the 36-character hyphenated string.
• Is a UUID a good idempotency key? Yes, as long as it's generated once by the client and reused on retries of the same logical operation — regenerating a new UUID on every retry defeats the purpose.