Free UUID Generator
Random version 4 UUIDs, generated locally with a cryptographic random source.
A UUID is a 128-bit identifier written as 36 characters, designed so that anyone can generate one at any time without coordinating with anyone else and still be confident it is unique. Version 4 fills almost all of those bits with random data. This generator uses crypto.getRandomValues, the browser’s cryptographically secure source — not Math.random, which is predictable and unsuitable for identifiers that must not be guessable.
How it works
Choose a quantity
One, or up to five hundred at a time.
Pick a format
Lowercase, uppercase, without hyphens or in braces.
Copy them out
One per line, ready to paste into code or a database.
How version 4 works, and why collisions are not a worry
A version 4 UUID is 128 bits, of which 122 are random — the remaining six are fixed to mark the version and variant, which is why the thirteenth character is always 4 and the seventeenth is always 8, 9, a or b. That leaves 2122 possible values, a number with 37 digits.
The practical consequence: you would need to generate roughly 2.7 quintillion UUIDs before reaching a 50% chance of a single collision. Generating a billion per second, that takes about 85 years. For any realistic application, treating version 4 UUIDs as unique without checking is entirely reasonable — which is the whole point of the format, since it means separate systems can create identifiers independently and merge the results without coordination.
This matters more than it sounds. A database using auto-incrementing integers needs a central authority to hand out the next number. UUIDs remove that constraint, which is why they appear in distributed systems, offline-capable apps that create records before syncing, and any situation where two systems must merge data without renumbering.
Where UUIDs cost you, and what to use instead
They are not free. A UUID stored as text takes 36 bytes against 4 or 8 for an integer, and as a primary key that overhead is repeated in every index and every foreign key referencing it. Storing them in a native uuid or BINARY(16) column rather than as a string recovers most of that.
The subtler cost is index locality. Random UUIDs scatter inserts across a B-tree instead of appending at the end, which fragments the index and hurts write performance on large tables. This is why version 7 exists: it puts a timestamp in the high bits so identifiers sort roughly by creation time, keeping inserts sequential while staying collision-resistant.
Finally, a UUID is not a secret. It is unguessable in practice, but it appears in URLs, logs and browser history. Use it as an identifier, not as an access token — "anyone with the link can view" is a deliberate design decision, not a security model.