UUID Generator
Generate random UUIDv4 or time-ordered UUIDv7 identifiers in bulk, using your browser’s cryptographic random source.
Runs entirely in your browserRelated Tools
Why Identifiers Get Generated Instead of Counted
An auto-incrementing number is the obvious way to identify rows, and it works fine until you have more than one thing creating them. Two servers, an offline mobile client, a data import, a merge between two databases — each needs to mint an identifier without asking anyone else first.
A UUID is 128 bits chosen so that collisions are effectively impossible without coordination. Any machine can generate one at any moment and be confident nobody else will produce the same value.
v4 or v7?
UUIDv4is 122 bits of pure randomness. It is the version most people mean by “a UUID”, it leaks nothing about when or where it was created, and it has been the default for two decades.
UUIDv7 is newer, standardised in RFC 9562 in 2024. Its first 48 bits are a millisecond timestamp, with the rest random. That makes v7 values sort in creation order, which matters enormously if they are used as database primary keys.
The reason is index behaviour. Databases store primary keys in a B-tree, and random keys scatter inserts across the whole structure — every write touches a different page, caches thrash, and the index fragments. Sequential keys append to the end, which is dramatically faster on large tables. Teams have historically worked around this with elaborate custom schemes; v7 solves it in the standard.
The trade is that a v7 identifier reveals roughly when it was created. If that matters — a public identifier where creation time is sensitive — use v4.
On Collisions
The usual reassurance is a huge number, but the useful framing is this: to reach a 50% chance of a single collision among random v4 UUIDs, you would need to generate about 2.7 quintillion of them. At a billion per second, that takes roughly 85 years.
The one real caveat is the random source. A UUID is only as unique as the randomness behind it, and there are documented cases of broken generators producing duplicates. This tool uses the browser’s cryptographic generator, which is the correct source — not Math.random().
Technical notes
- Randomness:
crypto.randomUUID()where available, otherwisecrypto.getRandomValues()with the version and variant bits set by hand - v7 layout: 48-bit big-endian millisecond timestamp, version nibble
7, variant bits10, remainder random - Ordering: UUIDs generated in the same millisecond are given increasing timestamps so the batch stays sorted
- Format: canonical 8-4-4-4-12 hexadecimal, lowercase by default
- Nothing is transmitted — values never leave the tab
Where UUIDs Belong, and Where They Do Not
UUIDs solve one problem well: letting several independent parties create identifiers without coordinating. That makes them right for distributed systems, offline-capable clients, event and message identifiers, idempotency keys, and correlation IDs that follow a request across services.
They are the wrong choice in a few common places. In a URL a human will read or type, a 36-character string is hostile — a short slug or a short code is better. As a security token, a UUID is unique but not designed to be unguessable, and v7 additionally reveals its creation time. And in a small single-database application, an auto-incrementing integer is smaller, faster, and easier to debug; UUIDs there are cargo cult rather than architecture.
FAQ
Can two UUIDs ever be the same?
In theory yes, in practice no. Reaching a 50% chance of one collision requires around 2.7 quintillion v4 UUIDs. The realistic risk is a faulty random source, not the mathematics.
Should I use UUIDs as database primary keys?
They are excellent for distributed systems, but random v4 keys hurt index performance at scale because inserts scatter across the B-tree. Use v7 if you want the distributed benefits without that cost.
Are UUIDs secret?
No. They are unique, not unguessable in a security sense, and v7 additionally reveals creation time. Never use one as a password, session token, or capability URL on its own.
Does case matter?
No. The specification defines UUIDs as case-insensitive, and lowercase is the conventional output. The uppercase option exists because some legacy systems expect it.
What happened to versions 1, 3, and 5?
v1 embeds a MAC address and timestamp, which leaks hardware identity. v3 and v5 are deterministic hashes of a name within a namespace — useful when the same input must always yield the same UUID, but not what people generally want from a generator.
Are UUIDs a good choice for URLs users will see?
Rarely. Thirty-six characters is unpleasant to read, type, or dictate over the phone. A short slug or short code reads far better, with the UUID kept internally.
Do I need UUIDs in a small application?
Usually not. If a single database creates every record, an auto-incrementing integer is smaller, faster to index, and easier to debug. UUIDs earn their cost when several systems mint identifiers independently.
How much space does a UUID take in a database?
Sixteen bytes stored natively, or thirty-six characters if stored as text. The text form is four times larger and slower to index, so use the native UUID type where your database offers one.
⚠️ Reference Only
Output is generated based on your input and is provided for reference. Results may vary depending on your specific use case, edge cases, or environment-specific behavior. We do not guarantee accuracy of conversions, validations, or computed values.
Always verify critical outputs against official documentation or production environments. We are not responsible for any decisions or losses based on these tool results.