UUID Generator (v4 and v7)
Generate random UUID v4 or time-sortable UUID v7 identifiers in bulk, using your browser's cryptographic randomness.
This tool runs entirely in your browser. Nothing you enter is uploaded to a server.
Generate UUIDs in bulk — random v4, or time-sortable v7 for database keys. They are produced by your browser's cryptographic random number generator, so no identifier is ever transmitted or logged by us. Choose uppercase or brace-wrapped output if your target system expects it.
How to use it
- Choose a versionv4 for general-purpose random identifiers, v7 when the values will become database keys and you want them to sort by creation time.
- Set how manyBetween 1 and 1000. The list regenerates whenever you change any option.
- Copy themCopy all puts the whole list on your clipboard, one identifier per line.
What the parts mean
A UUID looks like 0192f8c1-4d3e-7a2b-9c1d-5e6f7a8b9c0d. The digit beginning the third group is the version — 4 or 7 here — and the first digit of the fourth group encodes the variant, which is why it is almost always 8, 9, a or b. Those bits are fixed by the specification, which is why a UUID has 122 random bits rather than 128.
Why v7 exists
Random UUIDs have a well-documented cost as database primary keys. Databases store indexes as balanced trees ordered by key. Insert sequential keys and each new row goes at the end, touching one page. Insert random keys and every row lands somewhere different, so the database keeps loading and splitting pages all over the index. On a large table the write slowdown and the disk churn are substantial.
v7 fixes this without giving up independent generation. Because the leading 48 bits are the current time in milliseconds, identifiers made close together sort close together, so inserts cluster the way sequential integers do. You keep the ability to generate keys anywhere, and lose the index fragmentation.
One detail matters if you generate them in bulk. A loop produces thousands of identifiers inside a single millisecond, and if the bits after the timestamp were purely random they would sort arbitrarily — losing exactly the property you chose v7 for. This generator uses the monotonic counter the specification allows, so a batch of a thousand comes out in order rather than merely grouped by millisecond.
It was standardised in RFC 9562 in 2024, replacing a decade of homegrown variants that solved the same problem incompatibly.
Where UUIDs are worth it
They are the natural choice when identifiers must be created without coordination — offline mobile clients, several services writing to the same table, or data merged from systems that each had their own counter. They also avoid leaking business information: a sequential integer in a URL tells anyone who looks roughly how many records you have and lets them guess neighbouring ones.
The trade-off is size and readability. A UUID takes 16 bytes stored properly, or 36 characters as text, against 4 or 8 for an integer, and nobody reads one aloud. For a small single-database application, an auto-incrementing integer is usually the better engineering choice.
Privacy
Every identifier is produced by your own browser using the same random source the platform uses for cryptography. None of them reach us — there is no server involved — so no list of generated values exists anywhere but your screen.
Frequently asked questions
What is a UUID?
A 128-bit identifier, written as 32 hexadecimal digits in five hyphen-separated groups. The point is that anyone can generate one independently, without a central registry, and it will still be unique in practice. That makes them ideal for distributed systems, offline clients and merging data from several sources.
What is the difference between v4 and v7?
v4 is 122 random bits and nothing else. v7 puts a 48-bit millisecond timestamp at the front, followed by a counter and random bits. Both are unique; the difference is ordering. Sorting v7 identifiers as text also sorts them by creation time, which v4 cannot do.
Do bulk-generated v7 identifiers still sort correctly?
Yes. Generating a thousand identifiers takes well under a millisecond, so they would all share a timestamp — and with purely random tails they would sort arbitrarily, defeating the point. This generator uses the monotonic counter that RFC 9562 permits, giving 4096 ordered values per millisecond before rolling into the next one. Generate a thousand and they come out in order.
Which should I use?
Use v7 for anything that becomes a primary key in a database. Random v4 keys scatter inserts across a B-tree index, which fragments it and slows writes as the table grows — a well-known problem with UUID primary keys. v7 keys are near-sequential, so inserts land together and the index stays healthy. Use v4 when you specifically do not want creation time to be inferable.
Can two UUIDs ever collide?
In theory yes, in practice no. A v4 UUID has 122 random bits, about 5.3 undecillion possibilities. You would need to generate roughly 2.7 quintillion of them before reaching a one-in-a-billion chance of a single collision. It is not a guarantee in the mathematical sense, but it is a safer bet than most things a system depends on.
Are these random enough to be secret?
They come from crypto.getRandomValues, the browser's cryptographically secure generator, so a v4 UUID is unpredictable. That said, UUIDs are identifiers rather than secrets — they routinely appear in URLs and logs. If you need a token nobody can guess or replay, use a purpose-built secret with an expiry, not a UUID.
Does v7 leak when something was created?
Yes, deliberately. The timestamp is readable by anyone holding the identifier. That is the feature, but it means v7 is the wrong choice if the creation time is itself sensitive.
Are these sent anywhere?
No. Generation happens entirely in your browser, and nothing is stored. Reload the page and every identifier you saw is gone.