UUID Generator
Generate random v4 UUIDs instantly, singly or in bulk.
How to use UUID Generator
- Press generate — a fresh v4 UUID appears immediately.
- Ask for a batch if you need many, for seed data or test fixtures.
- Copy the value, or the whole list at once.
- Refresh whenever you need more — each one is independently random.
What is UUID Generator?
Generate a UUID. Press the button for a fresh identifier, or ask for a batch and copy the whole list.
A UUID is a 128-bit identifier written as 36 characters — 32 hex digits in five hyphen-separated groups:
f47ac10b-58cc-4372-a567-0e02b2c3d479\n8-4-4-4-12
The point of a UUID is that it can be created anywhere, by anyone, without coordination, and still be unique. No central database hands them out, no counter has to be shared between servers.
About the UUID Generator
Version 4 is what this tool generates and what almost everyone means by "a UUID": 122 random bits, with 6 bits fixed to mark the version and variant. You can spot one by the 4 that always starts the third group.
On collisions: 122 random bits is 5.3 × 10³⁶ possibilities. To reach a 50% chance of a single collision you would need to generate about 2.7 × 10¹⁸ UUIDs — roughly a billion per second for 85 years. In practice, a v4 collision is not a risk worth engineering against, provided the source of randomness is sound. This generator uses the browser's crypto.getRandomValues(), which is cryptographically secure; Math.random(), which some naive generators use, is not, and can produce predictable values.
The versions you are most likely to meet:
- v4 — random. The default choice.
- v7 — timestamp-first, standardised in 2024. Same uniqueness, but because the leading bits increase over time, v7 values sort chronologically and index far better.
- v1 — timestamp plus MAC address. Largely retired: it can leak the generating machine's hardware address and the time of creation.
When a UUID beats an auto-increment ID: when records are created on multiple servers or offline clients that later sync; when you do not want row counts leaking through sequential IDs in URLs; when a client needs to know an ID before the server confirms the insert.
The database trade-off is real: a UUID is 16 bytes against 4 or 8 for an integer, and because v4 values are random they scatter writes across a B-tree index instead of appending at the end — measurably slower inserts on large tables. If you need UUIDs and care about index performance, v7 is the modern answer.