UUID Generator
Generate RFC 4122 UUIDs in bulk. Version 4 is fully random; version 7 embeds a timestamp so IDs sort chronologically — a better default for database primary keys.
Output
Anatomy of the first UUID
How to use this tool
- Choose v4 for general-purpose random identifiers, or v7 if the IDs will become database primary keys.
- Set how many you need — up to 500 at a time.
- Pick a format: lowercase is the RFC-canonical form, no-dashes suits compact storage, braces match the Microsoft/COM convention.
- Click Generate for a fresh batch, then Copy all to grab the whole list.
- Check the Anatomy panel to confirm the version nibble and, for v7, the timestamp that got embedded.
A UUID is a 128-bit identifier designed so that independent systems can mint IDs simultaneously without coordinating and still never collide. That property is what makes them valuable in distributed systems: no central sequence, no lock, no round-trip to a database just to learn what the next ID should be.
Version 4 is the one most people mean by ‘UUID’ — 122 random bits with 6 bits reserved for version and variant markers. The collision math is reassuring: you would need to generate roughly 2.7 quintillion v4 UUIDs before reaching a 50% chance of a single duplicate. For any realistic application, treat collisions as impossible. This tool sources randomness from the Web Crypto API, not Math.random(), so the output is cryptographically secure.
Version 7 is newer, standardised in RFC 9562, and is usually the better choice for database primary keys. It places a 48-bit Unix millisecond timestamp in the leading bits, which means v7 UUIDs sort chronologically as plain strings. That single property fixes the biggest practical problem with v4 as a primary key: index fragmentation. Random keys scatter inserts across the whole B-tree, causing page splits and cache misses, whereas time-ordered keys append to the end of the index the way an auto-increment integer does.
The tradeoff with v7 is that it leaks creation time. Anyone holding the ID can read the millisecond it was minted — which this tool demonstrates in the Anatomy panel. That is usually harmless and often useful, but if the creation time of a record is sensitive, or if IDs are user-facing and sequential-looking IDs would let someone estimate your growth rate, prefer v4.
One practical note on storage: a UUID is 16 bytes of binary but 36 characters as text. Storing it in a CHAR(36) column more than doubles the space and slows every index comparison. PostgreSQL has a native uuid type and MySQL can use BINARY(16) — use them. The dashes are a display convention, not part of the value.
Frequently asked questions
Should I use UUID v4 or v7 for my database primary key?
v7, in almost every case. Its embedded timestamp makes IDs sort chronologically, so inserts append to the end of the index instead of scattering randomly through it. That avoids the page splits and write amplification that make v4 primary keys slow at scale. Choose v4 only if the record’s creation time must stay private.
Are these UUIDs cryptographically secure?
Yes. Generation uses crypto.randomUUID() and crypto.getRandomValues() from the Web Crypto API, which draw from the operating system’s CSPRNG. They are not derived from Math.random(), which is predictable and unsuitable for anything security-relevant.
What happened to UUID v1 and v6?
v1 embeds the machine’s MAC address and a timestamp, which leaks hardware identity and creation time — it fell out of favour for privacy reasons. v6 is a reordered v1 that sorts correctly but keeps the MAC-address baggage. v7 achieves the same sortability using a plain Unix timestamp and random bits, with no hardware identifier, which is why it superseded both.
Can two UUIDs ever be the same?
Mathematically yes, practically no. For v4 you would need around 2.7 quintillion UUIDs for a 50% chance of one collision. The realistic risk is not the math but a broken implementation — a weak random source, or a library seeding from the clock. Using the Web Crypto API, as this tool does, removes that risk.
Are UUIDs generated on your server?
No. Every UUID on this page is generated inside your browser and never transmitted anywhere. Reload the page and you get a completely different set. Nothing is logged or stored.