v4 or v7?
Both are 128-bit identifiers you can use without worrying about collisions. The difference is whether they sort.
| v4 (random) | v7 (time-ordered) | |
|---|---|---|
| Makeup | All 122 bits random | First 48 bits are a millisecond timestamp, the rest random |
| Sorting | Not possible | String order = creation order |
| Database index | Inserts land all over, fragmenting the index | Appends neatly at the end |
| What it reveals | Nothing | The time it was created |
For a database primary key, v7 is the better choice. Use v4 there and every new row lands at a random point in the index, so writes get noticeably slower as data piles up. Conversely, for a token that appears in a public URL, v4 is right — it leaks no timestamp.
Odds of a duplicate
v4 has 122 random bits. Generate a billion a second for a hundred years and the collision probability is still negligible. UUID collisions are not something to plan around.
That assumes good randomness. This tool uses the browser's cryptographic
generator (crypto.getRandomValues). A UUID built from Math.random() is
predictable and must never back a token or a password-reset link.
Formatting
The standard notation is lowercase with four hyphens (8-4-4-4-12). Uppercase and
braces ({...}) are how Microsoft platforms have written GUIDs, and the unhyphenated
32 characters save storage. All three are the same value, so passing them between systems is
only a matter of agreeing on the shape.
Is a GUID different from a UUID?
No. GUID is simply Microsoft's name for it.
Why is there no v1?
v1 embeds the network card's MAC address, which identifies the machine and raises privacy problems — and a browser cannot read a MAC address anyway. If you want time ordering, use v7; it was created to replace v1.