UUID Generator

The tool above generates version 4 UUIDs in your browser, up to 100 at a time, and nothing it produces leaves your device. I skipped the standard overview and organized this page around the six questions about UUIDs that come up most often.

The questions that keep coming up

Should I use UUID v4 or v7 for my database keys?

v4 is 122 bits of pure randomness. v7, standardized in RFC 9562 in 2024, places a Unix timestamp in the high-order bits so values sort by creation time, which keeps database index inserts clustered near the end of the B-tree instead of scattered across it. This tool generates v4, which suits tokens, trace IDs, and any identifier where ordering is irrelevant. For a new primary key column, prefer v7 if your language or database can produce it.

Is crypto.randomUUID safe enough for security tokens?

Yes. The browser's crypto.randomUUID draws from the operating system's cryptographically secure random source, so the output is unguessable in any practical sense. This tool calls it whenever it is available and falls back to crypto.getRandomValues, the same secure source, in the rare contexts where it is not. Avoid Math.random for anything security-related; it was never designed to resist prediction.

What are the odds of two UUIDs colliding?

For v4, the chance that two specific UUIDs match is about 1 in 2^122. The birthday math says you would need to generate roughly 2.7 quintillion UUIDs before reaching a 50 percent chance of a single collision anywhere in the set. Real collisions almost always trace back to a broken generator (bad seeding, cloned virtual machine entropy, copy-pasted values) rather than to the math. If a duplicate would corrupt data, add a unique constraint and let the database catch it.

Is a GUID different from a UUID?

No, both names describe the same 128-bit format. GUID is the term Microsoft adopted across Windows, .NET, and SQL Server, while UUID is what the RFC and most other platforms use. Some Microsoft tooling prints GUIDs in uppercase or wrapped in braces, but the underlying bytes parse identically.

Do I need a UUID, or will an auto-increment integer do?

If one database issues every ID, an integer sequence is smaller, faster to index, and easier to read in logs. UUIDs earn their 16 bytes when separate services must mint IDs without coordinating, when clients create IDs before the server sees the record, or when sequential IDs would leak volume or invite URL enumeration. Many systems carry both: an internal integer key plus a public UUID.

How does bulk generation work, and why the 100 limit?

Each UUID in a batch comes from its own independent random draw; there is no seed or derived sequence, so a batch of 100 is as safe as 100 single generations. I capped the count at 100 because that covers test fixtures and mock data without turning the page into an endless scroll. If you need thousands, run a loop around crypto.randomUUID in your own code, which is all this tool does under the hood.