About UUID Generator
A UUID is a 128-bit identifier designed to be unique without any central authority issuing it. Any system, anywhere, can generate one and rely on it not colliding with anyone else's. That property is what makes UUIDs the default choice for distributed systems, offline-capable applications and database primary keys that must be assigned before a record reaches the server.
Version 4 UUIDs are almost entirely random — 122 bits of it. The collision probability is so small that generating a billion per second for a century would still leave the odds of a single collision negligible.
Version 7 is newer and often the better choice for database keys. It puts a millisecond timestamp in the high bits, so UUIDs generated later sort after earlier ones. That ordering matters more than it sounds: random v4 keys scatter inserts across a B-tree index, fragmenting it and slowing writes, while sequential v7 keys append cleanly at the end.
How to generate UUIDs
Choose a version
v4 for pure randomness, v7 when you want identifiers that sort chronologically.
Set the quantity
Generate one, or up to ten thousand at a time for seeding a database.
Pick a format
Standard hyphenated, uppercase, without hyphens, or wrapped in quotes and commas ready to paste into code.
Copy or download
Copy the list to your clipboard or save it as a text file.
v4 or v7?
- v4 — fully random. Use it for API keys, correlation IDs, file names and anywhere the identifier should reveal nothing.
- v7 — timestamp-prefixed and sortable. Use it for database primary keys, event IDs and anything that benefits from chronological ordering.
- Note that v7 leaks its creation time to anyone holding it. That is usually harmless, and occasionally not — avoid it where the timing itself is sensitive.
Why v7 helps databases
Database indexes are trees kept in sorted order. Inserting random values means every new row lands in an unpredictable place, splitting pages and scattering writes across the disk. Insert throughput degrades measurably as the table grows.
Time-ordered keys always append near the end of the index, so pages fill sequentially and stay dense. Teams that switch from v4 to v7 primary keys on write-heavy tables routinely see meaningful improvements in insert performance and index size.