Generate UUIDs
Private — your file is never stored
Which version?
Your 0 UUIDs appears here.
How it works
Pick a version
v4 for anything that must be unguessable. v7 for database keys. The difference is explained on the page rather than assumed.
Choose how many
One, or up to ten thousand at once, with optional formatting — uppercase, braces, no hyphens, or as a quoted list ready for code.
Copy them
Copy all, or download as a text file.
Version 4 or version 7, and why it matters in a database
A UUID is 128 bits written as 32 hex digits in the familiar 8-4-4-4-12 grouping. Six of those bits are spent saying which version and variant it is, which leaves 122 random bits in a version 4 — enough that you could generate a billion a second for a century and still be overwhelmingly unlikely to see the same one twice. That is the whole appeal: two systems that have never communicated can both mint identifiers and safely assume they will never collide.
The randomness has to be real for that to hold, and here it comes from the cryptographic random source rather than an ordinary random number generator. The difference matters when identifiers are used as capability tokens — a password reset link, an unguessable share URL — because a predictable generator lets someone work out the next value from previous ones. With a cryptographic source there is nothing to predict.
Version 7 exists because version 4 behaves badly as a database primary key. It puts a 48-bit millisecond timestamp at the front and fills the rest with randomness, so UUIDs generated in sequence sort in the order they were created. That sounds cosmetic and is not: a random key scatters every insert across the whole index, so each write touches a different page and the cache stops helping, while a time-ordered key appends to one end. On a large table the difference in insert throughput is substantial, and it is the reason v7 was standardised.
The trade is real and worth weighing. A version 7 UUID tells anyone who sees it roughly when it was created, to the millisecond, and a run of them reveals how fast you create records. For an internal key that is fine. For an identifier exposed in a URL — an order number, a document link, a user id — it is a small information leak that version 4 does not have. Use v7 for the primary key and v4 for anything public if both matter.
When you want something else
Generate them where they are used. Every database and language has this built in — gen_random_uuid() in PostgreSQL, UUID() in MySQL, crypto.randomUUID() in JavaScript, uuid.uuid4() in Python — and generating a batch in a browser and pasting them into code is fine for a fixture or a test and wrong for anything that runs.
If the reason for v7 is sortable keys, there are alternatives worth knowing about. ULID encodes the same idea in 26 characters that are shorter and case-insensitive; Snowflake identifiers fit in 64 bits, which halves the index size against a UUID's 128. And in many databases an ordinary auto-incrementing integer is still faster and smaller than any of them — UUIDs are worth their cost when identifiers must be minted in several places at once, and not otherwise.
Frequently asked questions
v4 or v7 — which do I want?
If it is a database primary key, v7. If it must be impossible to guess — a password reset link, an invite code, a session identifier — v4. That is the whole decision, and most people never learn there was one, because almost every generator offers only v4.
Why is v4 bad as a database key?
Because it is completely random, and a database index is sorted. New random keys land in random places in the index, so every insert touches a different page, the cache stops helping, and the index fragments and grows. On a large busy table this is a measurable slowdown that gets worse over time. It is not a theoretical concern — it is the reason Postgres and MySQL documentation now both discuss it.
What is UUID v7?
A UUID whose first 48 bits are a millisecond timestamp, followed by randomness. It is still globally unique and still 128 bits, but because the time comes first, v7 UUIDs sort in the order they were created. New keys append to the end of the index instead of scattering through it, which is exactly how an auto-incrementing integer behaves — with the uniqueness of a UUID. It was standardised in RFC 9562 in 2024 and it is the current recommendation for new tables.
Do the v7 UUIDs here actually sort?
Yes, including within the same millisecond, which is the part most implementations get wrong. A timestamp only has millisecond resolution, so generating a thousand IDs in a loop finishes inside one — and with purely random low bits those thousand do NOT sort into the order they were made. This generator uses the monotonic counter described in RFC 9562, so a batch is strictly ascending, every time. Generate a thousand and sort them; they come back in the order they were created.
Is a v7 UUID safe to expose publicly?
With one thing in mind: it reveals when it was created, to the millisecond, by design. For a database key that is usually harmless or even useful. But if the creation time is itself sensitive, or if you need the identifier to be unguessable, use v4 — v7 still has 74 random bits, which is a great deal, but its timestamp is plainly readable by anyone who has the ID.
Are these random enough to be secure?
Yes. Randomness comes from `crypto.getRandomValues`, the browser's cryptographically secure generator, never from `Math.random`. That distinction has caused real vulnerabilities: `Math.random` is fast but predictable, and session tokens built on it have been guessed in practice. A v4 UUID has 122 random bits, which is enough that collisions are not a practical concern.
Are the UUIDs stored or logged?
No, and for identifiers that matters. A UUID that someone else has seen defeats the purpose if you are generating a secret. Nothing generated here is stored or logged.
What is the nil UUID?
All zeroes: 00000000-0000-0000-0000-000000000000. It is a valid, reserved UUID used to mean "none" or "not set" where a null is not possible. Its opposite, the max UUID of all fs, is sometimes used as a sort sentinel. Both are offered here because they are occasionally needed and awkward to type correctly.
Good to know: Version 4 UUIDs come from the browser's cryptographic random source, not Math.random, so they are safe to use as identifiers. Version 7 embeds a millisecond timestamp, which is what makes it sort well — and also means it leaks roughly when it was created. Do not use v7 where that matters.
Put this tool on your website
Free for any blog, class page or help article. Paste one snippet and your visitors can use it right on your page.