UUID generator · formatUUID v4 — generator and how it works
Version 4 is 122 random bits plus six fixed ones. Nearly every library and database hands it out by default: it reveals nothing about where or when it was made and needs no coordination between machines.
An ID that must give nothing away: tokens, request keys, names of uploaded files.
A primary key for a small table or a distributed system where insert order does not matter.
Anywhere you need “just a unique ID” — it is the default.
How it differs from its neighbours
The main neighbour is v7. Version 4 has no order: new values land all over the range, so in a large table indexed by the key each insert goes to a random spot in the index. Version 7 starts with the time and is appended at the end. For tables growing into millions of rows pick v7; otherwise the difference does not show.
Almost everywhere it is one built-in call: crypto.randomUUID() in browsers and Node.js, uuid.uuid4() in Python, UUID.randomUUID() in Java, Guid.NewGuid() in C#, and gen_random_uuid() in PostgreSQL from version 13. All of them produce version 4 from a cryptographic generator. A third-party library is only needed for old environments that lack these functions.
That is the version number: the first digit of the third group stores it in four bits, and for version 4 it is always 4. The first digit of the fourth group is the variant, which for RFC 9562 is 8, 9, a or b. Six of the 128 bits are fixed, so v4 has exactly 122 random ones, and those two positions let you spot the version by eye.
Only if it comes from a cryptographic generator, as here and in crypto.randomUUID: then 122 bits cannot be guessed by brute force. But RFC 9562 explicitly advises against treating UUIDs as secrets — some libraries use an ordinary pseudo-random generator, and logs or address bars easily expose the value. For access tokens, a dedicated secret generator with an explicit length is safer.
Because it has no order. A database index is a sorted tree, and every new random value lands on a random page of it: pages split, caching suffers and the index bloats. Small tables never show it; tens of millions of rows do. The key also takes 16 bytes against 8 for an integer. That is why large tables use v7 for keys.
For the key of a large table and anything handy to sort by the ID itself, choose v7: it is ordered by creation time. For values that outsiders see, choose v4: it reveals nothing about when the record appeared. If you are unsure and the table is small, there is no practical difference, and v4 remains a safe default.
Look at the first digit of the third group, which must be 4, and the first digit of the fourth group: 8, 9, a or b. The Check field on the generator page does it strictly: it accepts values with or without hyphens, in braces or with the urn:uuid prefix, names the version and variant and shows which parts the identifier is made of.