About the UUID Generator
A UUID generator produces 128-bit identifiers that any machine can mint independently, with no central authority handing out numbers. This one emits RFC 4122 version 4 UUIDs — the fully random variant — in batches of up to fifty, with switches for uppercase output and for stripping the hyphens when your storage layer wants a bare 32-character hex string. The panel underneath confirms the version, the 122 random bits and the resulting string length. Output is seeded and therefore repeatable, which suits fixtures and documentation examples but rules the tool out for security tokens.
How to use the UUID Generator
- 1
Leave Version set to Version 4 (random), the only variant this tool emits.
- 2
Enter How many identifiers you need, from 1 up to 50 per run.
- 3
Toggle Uppercase if your schema stores UUIDs in capitals, and untick Include hyphens for the compact 32-character form.
- 4
Click Generate, then use the copy control or download the batch as uuids.txt.
What people use it for
Seeding a database migration
When a migration needs stable primary keys for reference rows, paste a generated batch into the SQL rather than calling a UUID function at runtime, so every environment ends up with identical identifiers.
Correlation IDs in API documentation
Example requests read better with realistic identifiers than with placeholders like xxxx. Generate a handful of well-formed UUIDs to drop into your OpenAPI examples.
Naming resources in infrastructure code
Cloud resources that need a globally unique suffix often take a hyphen-free UUID. Turn hyphens off and you have a 32-character token that fits most naming constraints.
Deduplicating imported records
Spreadsheets merged from several sources rarely share a key. Generate one UUID per row so downstream systems have something unambiguous to join on.
Where the 122 random bits come from
A UUID is 128 bits written as 32 hexadecimal digits. In version 4, six of those bits are spent on metadata rather than randomness. Four bits encode the version: they occupy the high nibble of the seventh byte, which is why the thirteenth hex digit of a v4 UUID is always the literal character 4. Two more bits encode the RFC 4122 variant: they sit at the top of the ninth byte and are fixed to binary 10, which forces the seventeenth hex digit to be 8, 9, a or b. Everything else — 122 bits — is random, leaving 2^122 distinct values, roughly 5.3 undecillion. The layout is also why you can identify a v4 UUID by eye: in the canonical 8-4-4-4-12 grouping, the third group starts with 4 and the fourth group starts with one of those four characters.
Collision probability in practical terms
Collisions follow the birthday bound rather than naive intuition. The chance of at least one duplicate after n draws from 2^122 values is approximately n squared divided by 2 to the power of 123. Setting that to one in a billion and solving gives roughly 2.7 quintillion UUIDs before a single collision becomes even a one-in-a-billion event. Generating a billion UUIDs every second, you would need something on the order of 85 years to reach that point. For any real application the risk sits far below the risk of a disk quietly returning corrupted data. The caveat is that this reasoning assumes genuinely uniform random bits: a weak or badly seeded random source collapses the effective space dramatically, and that is the actual cause of every real-world UUID collision ever reported.
Choosing v4 against v7 and ULID
Fully random UUIDs are unfriendly to storage engines. In a clustered B-tree index — the default in MySQL InnoDB and in any table whose primary key determines physical row order — inserts land at random positions, so pages split constantly and the set of hot pages grows to the size of the whole index. UUID version 7, standardised in RFC 9562, addresses this by putting a 48-bit Unix millisecond timestamp in the leading bits, so new rows append near the end of the index while the trailing random bits keep values unguessable within a millisecond. ULID takes the same approach with a Crockford base32 encoding that sorts lexicographically as text. Version 4 remains the right choice when you want no time information leaking out of the identifier, or when it is a secondary key rather than the clustering key.
Tips
- Store UUIDs in a native uuid or binary(16) column rather than char(36); it halves the storage and speeds up comparisons.
- Note the seed if you need to regenerate the same identifiers for a reproducible test fixture.
- For security tokens call crypto.randomUUID() in your own code — this tool is deliberately deterministic and therefore predictable.