Generates one to a hundred version 4 UUIDs using crypto.randomUUID() from the Web Crypto API, with or without hyphens, entirely in the browser. The design goal of a UUID is only that identifiers can be minted uniquely without coordination; it gives you no ordering, no meaning and no brevity. The absence of those three accounts for nearly every problem people hit when using them in a database or a URL.

Case	What happens	What to do
Using one as a primary key slows the database down	A version 4 UUID is entirely random, so insertions land scattered throughout the index. A B-tree is most efficient when appended to at the end, so random insertion causes frequent page splits and fragments the index. In MySQL InnoDB the primary key is the clustered index — the row data itself is ordered by primary key — so the effect is larger still: at tens of millions of rows, insertion is several times slower than with a sequential key and the index grows correspondingly. On top of that, storing it as `CHAR(36)` consumes four and a half times the space of a sequential `BIGINT` at eight bytes, in every foreign key and every index.	Use version 7, which sorts by time — its leading 48 bits are a Unix millisecond timestamp, so UUIDs sort in creation order and insertions concentrate at the end of the B-tree. It keeps the appearance and the uniqueness of a UUID and was designed specifically to solve this problem (standardised in RFC 9562). Where v7 is not available, keep a sequential internal primary key and hold the UUID in a separate column for external use. Revisit the storage type too: `BINARY(16)` instead of `CHAR(36)` more than halves the space, and PostgreSQL has a native `uuid` type. Start by asking whether you need a UUID at all — if you do not need distributed or offline generation, a sequence is enough.
Treating a UUID as if it were a secret	The random portion of a version 4 UUID is 122 bits, so guessing one is not realistic — and on that basis alone, designs appear that put a UUID in a URL and assume only someone who knows it can reach the resource. But a UUID is an identifier, not a value designed to be kept secret: put it in a URL and it lives on in browser history, referrer headers, access logs, proxy logs and shared links. Worse, version 1 embeds the MAC address and the generation time, so it is not even random — using v1 for a session id or a password reset token is dangerous.	Avoid designs where knowing the URL is what grants access. Access control belongs in authentication and authorisation; the difficulty of guessing a URL is at best a supplement. Where you genuinely need the URL itself to act as a key, as with a share link, use a purpose-built token rather than a UUID, and give it an expiry and a revocation path — 32 random bytes from `crypto.getRandomValues()`, Base64url encoded, is the standard construction. And keep that URL out of logs by putting it in the fragment (after the `#`) rather than the path, or by sending it in a POST: fragments are never sent to the server. A UUID says what something is; it does not prove who you are.
Formatting differences make one id look like two	A UUID has several permitted spellings: upper and lower case (`A1B2` versus `a1b2`), with or without hyphens (36 characters or 32), and wrapped in braces (`{...}`, a Microsoft convention). RFC 4122 specifies lower case on output and acceptance of either on input, but compared as strings these are all different values. In practice, one system returning upper case while another stores lower case creates duplicate records for the same entity — and because whether they match can depend on the database collation, the behaviour varies by environment and the cause becomes hard to pin down.	Normalise to one form at the edge of your system — hyphenated and lower case is the most common and matches the RFC recommendation. Run values received over an API through `toLowerCase()` before comparing or storing them. Storing them in a binary or native `uuid` column rather than a string is the real fix: in binary the spelling question simply does not exist, and the PostgreSQL `uuid` type absorbs input spellings and treats them as the same value. And validate wherever you accept a UUID — erroring on a malformed value at the boundary is far easier to trace than quietly creating a second record.

On collisions, worrying too much and worrying too little are both mistakes. A version 4 UUID carries 122 random bits, and generating a billion per second for a century still leaves the collision probability negligible — but that holds only when the randomness is cryptographically secure. Implementations that build UUIDs on top of Math.random() exist, and those do collide in practice. Embedded devices and freshly booted servers are especially short of entropy, and there are documented cases of several machines producing the same value. Use crypto.randomUUID() in a browser and your language cryptographic random API on a server. One more thing: crypto.randomUUID() is available only in a secure context — HTTPS or localhost. That is almost always the explanation when the function mysteriously does not exist on an internal HTTP setup.

📖 How to Use

1

Set the count

Enter a count from 1 to 100. Specifying multiple is handy when bulk-creating test data or DB primary keys.
2

Toggle hyphens and click Generate

Check "No hyphens" to toggle the format, then click Generate. UUIDs are generated with crypto.randomUUID() or Web Crypto API.
3

Use the bulk copy

Click the bulk copy button to copy all UUIDs to the clipboard, newline-separated. Ready to paste into SQL INSERT statements or JSON files.

❓ Frequently Asked Questions

What is UUID v4?

UUID v4 is a 128-bit random identifier defined in RFC 4122 and formatted as 8-4-4-4-12. Version 4 is randomly generated, making collision probability negligibly small in practice.

Is there a risk of collision?

In theory yes, but with 122 bits of randomness, generating 1 trillion UUIDs gives a collision probability below 0.000000001%. Negligible in practice.

Can UUID be used as a database primary key?

Yes. UUID is effective for avoiding duplicates in distributed or multi-server environments. However, UUID v4 is random, which can cause index fragmentation. For ordered inserts, consider UUID v7.

🐛 Found a bug or issue with this tool?

Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.

UUID v4 Generator

Other Tools

Related articles

📖 Where people get stuck

📖 How to Use

❓ Frequently Asked Questions

Thanks for your report!