UUID generator
Version 4 is random; version 7 is time-ordered and sorts chronologically. Use v7 for anything that will be a database key and v4 for everything else — both are generated here by your browser's cryptographic random source.
One at a time or a hundred, with uppercase and brace formatting for the platforms that want them.
Entirely random. The right default, and what most systems mean by "a UUID".
48f135af-990e-4588-ae8f-b25e9ef958ab
a021fe29-3ce4-4d61-b578-e77d7c1daa17
51bc0872-edf2-41d2-9805-a1ff619f16e4
6dec4936-39c8-4bf1-a74b-fb79f00e0cbe
4d468b25-6c6a-42a7-bdda-d0ab94b4f16cNothing is uploaded. Generated in this tab. No request carries it.
v7 exists because v4 makes a bad primary key
This is the practical difference and it is worth understanding before choosing. A database index is a sorted structure. When new keys are always larger than the existing ones, inserts append to the end — cheap, compact, and friendly to the page cache. When new keys land at random positions, the index splits pages all over itself, grows faster, and reads worse.
A v4 UUID is random by definition, so it does exactly the bad thing. A v7 puts a millisecond timestamp in the high bits, so today's keys are all larger than yesterday's and inserts append. The randomness is still there in the remaining bits, which is what keeps them unique.
| v4 | v7 | |
|---|---|---|
| Random bits | 122 | 74 |
| Sorts chronologically | No | Yes |
| Reveals creation time | No | Yes, to the millisecond |
| Good as a database key | Poor | Good |
| Good in a public URL | Yes | Yes, but it leaks a timestamp |
The collision question
A v4 carries 122 random bits. To reach a one-in-a-billion chance of any collision you would need to generate roughly 2.7 × 1018 of them. At a million a second that is about eighty thousand years. Collisions are not the thing to worry about.
What is worth worrying about is the source of the randomness. A UUID built from
Math.random has far less unpredictability than its 122 bits suggest, and its future values can be
reconstructed from a handful of observed ones. These use the browser's cryptographic generator.
Unguessable is not the same as authorised
UUIDs are often used as URL identifiers on the reasoning that nobody can guess one — which is true, and not a security model. A UUID is shared in emails, logged by proxies, kept in browser history and pasted into support tickets. It stops being unguessable the moment it is used.
Use them as identifiers and check permissions separately. And bear in mind that a v7 tells anyone holding it exactly when the record was created, which is occasionally more than you meant to say.
Questions
What is the difference between UUID v4 and v7?
A v4 is entirely random. A v7 puts a millisecond timestamp in its first 48 bits and fills the rest with randomness, so v7 values sort chronologically as plain strings. Both are equally unique in practice; v7 is dramatically better as a database key.
Which UUID version should I use?
v7 for anything stored as a primary key, v4 for everything else. If you are generating an identifier for a row in a table, v7 is the better choice and the reason is index behaviour rather than uniqueness.
Why is UUID v4 bad as a database key?
Because random keys scatter inserts across the whole index. A B-tree index appends cheaply when new keys are larger than the old ones, and fragments when they land anywhere — which means more page splits, a bigger index and worse cache behaviour. v7 sorts by time, so inserts append.
Can two UUIDs ever collide?
Not in any practical sense. A v4 has 122 random bits, so you would need to generate about 2.7 × 10^18 of them before a collision reaches even a one-in-a-billion chance. The real risk is not mathematics but a weak random source — which is why these are drawn from the browser’s cryptographic generator rather than from Math.random.
Are UUIDs secret?
Treat them as identifiers rather than secrets. A v4 is unguessable enough to be used in a URL, but a v7 leaks its creation time by design, and neither is a substitute for an access check. "Unguessable" and "authorised" are different things.
Are these generated on your server?
No — there is no server involved. They are produced in this tab by your browser’s cryptographic random number generator, and no request is made when you press the button. A UUID fetched from a website is one that website has a record of.
What BriskFile will not do to you
-
Your files never leave your device
Every conversion runs in your browser. Open DevTools, watch the Network tab, and you will see no upload — because there is not one.
-
No account, no email, no watermark
Nothing to sign up for and nothing stamped on your images. There is no step between choosing a file and getting it back.
-
No limits at the download button
No daily cap, no file counter, no "upgrade to download". If the tool starts a job, it finishes it.
-
Checkable, not just claimed
Open the Network tab and convert something — nothing goes out. Or load the page, disconnect, and watch it keep working: the tool is already on your machine, and your file never leaves it.