Generate Random UUID v4 Identifiers
Generate as many random v4 UUIDs as you need for databases and code, instantly.
The values never leave your device
Nothing is logged anywhere
Platform-grade randomness
Works in every modern browser
How it works
- 1
Choose a version
v4 unless the identifier is going into a database index, in which case consider v7.
- 2
Pick how many
One for a quick test, or a batch for seed data and fixtures.
- 3
Copy the result
Take it into a schema, a request, a configuration file, or a test.
Why use this tool
Version 4 and version 7
Random for general use, or timestamp-ordered when the value becomes a primary key.
Cryptographic randomness
Generated from the browser’s secure random source, not from a predictable pseudo-random function.
Bulk generation
One identifier or a thousand, produced in a single step and ready to paste into a seed file.
With or without hyphens
The canonical 36-character form or the bare 32-character one, whichever the destination expects.
Nothing is transmitted
The values are produced in your browser, so no third party ever learns which identifiers you used.
Free, no account
No signup, no watermark, no cap on how many you generate.
The version matters more than most people realise
People say UUID and mean version 4, which is 122 random bits and nothing else. That is the right default, but it is not the only version and the differences have consequences. Version 1 builds the identifier from a timestamp and the machine’s network hardware address, which means a v1 UUID quietly discloses when it was created and, historically, which machine created it — fine inside a system, awkward in anything a customer can see. Version 7, standardised recently, keeps the randomness but puts a millisecond timestamp in the leading bits, so the values sort chronologically. If you have ever generated a UUID without thinking about which kind it was, it was almost certainly v4, and for most uses that is the correct answer. The exception is the one below.
Random identifiers are hard on a database index
This is the most consequential practical fact about UUIDs and it surprises people who switch to them from integers. A database index is a sorted structure, and sorted structures like values that arrive in order. A sequence of integers appends to the end of the index, touching one page repeatedly and keeping it in memory. A stream of v4 UUIDs is random by design, so each insert lands in a different place, forcing the index to write to scattered pages, split them, and hold far more of the structure in cache to keep up. On a large table the difference is measurable and the symptom is the familiar story of a system that became slow after adopting UUID keys. Version 7 exists precisely for this: the leading timestamp makes new values sort near each other, so inserts stay local again while the identifiers remain unguessable.
A UUID is not a secret, unless you deliberately make it one
Two claims get muddled here and both matter. The first is that a v4 UUID is genuinely unguessable — 122 random bits is far beyond brute force — but only if the randomness is cryptographic. Plenty of code generates UUIDs from a general-purpose random function, which is fast and predictable, and identifiers from a predictable source can be enumerated by anyone who works out the seed. Check what your generator uses. The second is that even a perfect v4 is an identifier and not an authorisation. Using an unguessable UUID as a share link works, and it means the URL is the password: it will sit in browser history, in referrer headers, in a chat log, and in any email it was forwarded through. That is an acceptable design for a document link and an unacceptable one for anything that needs revoking.
What the collision guarantee actually says
The reason UUIDs work without coordination is a probability argument, and the numbers are worth knowing so you can stop worrying about them. With 122 random bits, you would need to generate roughly 2.7 quintillion version 4 UUIDs before there was a 50 percent chance that any two of them matched. At a million per second that is tens of thousands of years, which is why systems on opposite sides of the world can mint identifiers with no central registry and never coordinate. What the guarantee depends on entirely is the quality of the randomness. A weak or badly seeded generator collapses that number without any warning, and duplicate UUIDs in production almost always trace back to a flawed source rather than to bad luck — several well-known incidents involved devices that seeded their random source identically at boot.
Storing them costs more than you might expect
A UUID is 128 bits — 16 bytes — but the form you usually see is 36 characters of text, because the canonical representation writes each byte as two hexadecimal digits and adds four hyphens. Store that as a string and you are using 36 bytes per row rather than 16, plus whatever your database adds for a variable-length column, and every index on that column carries the same inflation. On a table of a few thousand rows nobody notices. On a table of a hundred million, in an index that has to stay in memory, it is the difference between fitting and not. Most databases have a native 16-byte type for exactly this reason, and using it is usually the right call. The formatting details are minor by comparison: hyphens are conventional rather than required, comparison is case-insensitive, and lowercase is the canonical output.
Why generating locally matters even for random values
It is fair to ask what privacy has to do with a random number, and the answer is that the number stops being anonymous the moment it is tied to something. A hosted generator sees every identifier it issues and can log them alongside the requesting address and the time. If those UUIDs then become order references, share links, API keys, or database identifiers in your system, someone else holds a list of valid values and a good idea of what they belong to. That is a small risk and an entirely unnecessary one, because generating locally removes it completely: your browser has a cryptographic random source built in, the values never leave the page, and you can confirm no request was made in the Network tab of your developer tools.
Common mistakes to avoid
- Using v4 UUIDs as database primary keys on a large table. Random values scatter index writes and fragment the structure — use v7, whose leading timestamp keeps inserts local while staying unguessable.
- Generating UUIDs from a general-purpose random function. Only a cryptographic source makes them unguessable; a predictable seed means an attacker can enumerate the identifiers.
- Treating an unguessable UUID as an authorisation. A share link built from one means the URL is the password, and URLs end up in history, referrer headers, and forwarded email.
- Storing a UUID as a 36-character string at scale. The value is 16 bytes; the text form more than doubles that in every row and every index — most databases have a native type.
- Using v1 in anything customer-facing. It encodes the creation time and historically the machine’s network hardware address, which is more than an identifier needs to reveal.
How it compares
| Aspect | This tool | Online generators | A library call |
|---|---|---|---|
| Values transmitted or logged | Never | Possible | No |
| v7 available | Yes | Rarely | Depends on the library |
| Cryptographic randomness | Yes | Usually unstated | Usually yes |
| Bulk generation | Yes | Sometimes | Yes |
| Works without a project open | Yes | Yes | No |
| Price | Free | Free / paid tiers | Free |
Features
UUID v4
The 122-random-bit version that most systems mean when they say UUID.
UUID v7
Timestamp-prefixed and therefore sortable, which is what a database index wants.
Uppercase or lowercase
Canonical form is lowercase; some systems insist on uppercase, and both are here.
Generate in bulk
Hundreds at once, one per line, ready for a seed script or a spreadsheet column.
Uses the platform CSPRNG
Values come from the browser’s cryptographic generator rather than a general-purpose one.
Instant, no request
Nothing is fetched, so generation is immediate and works with the tab already loaded.
Nothing to install
No library, no runtime, no dependencies — it runs on the web page.
Arabic and RTL ready
Full interface in eight languages, including right-to-left Arabic.
Secure by default
Served over HTTPS, with no tracking and no third-party requests.
Who uses it
Developers
Getting a valid identifier for a fixture or a manual database row without opening a console.
Database engineers
Producing v7 values when a table needs unguessable keys that still index well.
QA engineers
Generating a batch of unique identifiers for test data in one step.
API integrators
Creating an idempotency key or a correlation identifier for a request.
Frequently Asked Questions
No. Everything runs locally in your browser — your text is never uploaded, stored, or shared.
Yes — completely free, with no account and no limits.