UUID generator
v4 is pure randomness; v7 puts 48 bits of timestamp at the front, which makes identifiers increase over time — and that changes everything for a database index.
The draw uses crypto.randomUUID() or crypto.getRandomValues(), the browser's cryptographic API. Nothing is sent or stored.
How the check works
- 1
Pick the version
v4 for an identifier with no order and no meaning. v7 when identifiers are primary keys or index entries: they sort naturally by creation time.
- 2
The draw is cryptographic
122 bits of randomness for v4. Collision is theoretically possible and practically out of reach: it would take billions of identifiers per second for a century.
- 3
Version and variant bits are set
A conformant UUID carries its version number at the 13th hex character and its variant at the 17th. A generator that forgets them produces a string that looks like a UUID without being one.
Why v7 is often the better primary key
A B-tree index likes ordered inserts. With v4 UUIDs, every insert lands at a random spot in the index, fragments pages and inflates write volume. With v7, new rows append at the end, like an auto-incrementing id.
The price: a v7 UUID discloses its creation instant to the millisecond. Usually not a secret, but if creation order is itself sensitive, v4 remains the right choice.
Frequently asked questions
Can two UUIDs be identical?
Mathematically yes, practically no. A v4 UUID carries 122 bits of randomness: generating a billion per second for a hundred years would still leave a negligible collision probability. The real source of duplicates is a poorly implemented generator that does not use a cryptographic source.
What is the difference between v1, v4 and v7?
v1 combines a timestamp with the machine's MAC address, so it leaks hardware. v4 is pure randomness. v7, standardised in RFC 9562, keeps v1's temporal ordering without exposing hardware: today it is the best compromise for a primary key.
Should a UUID be stored as text or binary?
Binary where the database allows it: 16 bytes against 36 characters, more than halving the space in every index. PostgreSQL has a native uuid type; MySQL uses BINARY(16) with UUID_TO_BIN(). As text, you pay for that space on every row and every index entry.
The same check over API
This tool runs in your browser. To run the same check from your code, in bulk or server-side, the API answers in JSON.
Read the documentation