UUID Generator

Generate UUIDs and take them away in a usable shape. Version 4 for randomness, version 7 when you want ids that sort by creation time. Up to a million at once, as CSV, TSV, JSON, JSON Lines or a bare list, written lowercase with dashes, uppercase, dashless, braced or as a URN. Generated in your tab from the browser's cryptographic random source.

Twenty version 4 UUIDs are generated the moment the page loads. Change anything and it regenerates.

Version 7 exists because version 4 fragments your index

Version 4 is 122 random bits. That is exactly what you want for a token or a public identifier, and exactly what you do not want for a primary key in a table with a clustered index.

A B-tree index stores keys in order. Insert a sequential key and every insert lands at the right-hand edge of the tree, filling pages neatly. Insert a random key and every insert lands somewhere arbitrary, splitting pages all over the structure. On a large table that is the difference between an index that stays compact and one that fragments until a rebuild.

Version 7 fixes it without giving up uniqueness. The first 48 bits are a Unix millisecond timestamp, big-endian, and the remaining 74 bits are random. So the ids sort by creation time both as bytes and as text, and inserts land at the edge of the tree again.

v4  9c1f8a2e-4b7d-4a51-9e33-6f0c2d81b4a7
    3e70d5c1-88a2-4f19-b0e4-1a9c7d2e5f38
    f4a02b93-6c15-4d8e-8b27-9e5a3c0d1f46
    (no order at all)

v7  0199a4c2-3f80-7c11-a3e2-5d8b1e40f92c
    0199a4c2-3f81-7d44-9b07-2c6a8f31e5d0
    0199a4c2-3f82-7a09-8e51-4b3d9c72a16f
    (the leading digits climb, because they are the clock)

Version 7 is standardized and supported by Postgres, MySQL, most ORMs and every major language's UUID library. If you are choosing a primary key format today, it is usually the right answer. The one thing it gives up is that the creation time is readable from the id, which for a public identifier can matter.

Five written forms, and who wants which

Form	Looks like	Wanted by
Standard	`9c1f8a2e-4b7d-4a51-9e33-6f0c2d81b4a7`	everything, and the right default
Uppercase	`9C1F8A2E-4B7D-4A51-9E33-6F0C2D81B4A7`	Windows registry keys, some .NET code, older enterprise systems
No dashes	`9c1f8a2e4b7d4a519e336f0c2d81b4a7`	URL paths, filenames, MongoDB, anywhere 32 characters beats 36
Braced	`{9c1f8a2e-4b7d-4a51-9e33-6f0c2d81b4a7}`	COM and Windows APIs, which have written them this way for decades
URN	`urn:uuid:9c1f8a2e-4b7d-4a51-9e33-6f0c2d81b4a7`	RDF, XML documents, anywhere a formal URN is expected

They are all the same 128 bits. Uppercase and lowercase are equivalent for comparison purposes in every specification, though plenty of string comparisons in real code are not, which is the main practical reason to pick one and stick to it.

Where they come from

From crypto.getRandomValues, the browser's cryptographically secure random source, requested in the chunks the API accepts. Not from Math.random, which is fast, seeded from something predictable, and unsuitable for anything anyone might want to guess.

The version and variant bits are then pinned as the specification requires: the 13th hex digit becomes 4 or 7, and the 17th becomes one of 8, 9, a or b. Those two nibbles are what makes a UUID a UUID rather than 32 random hex characters, and they are the first thing a validator checks.

Version 7 ids generated in one batch are monotonic within that batch, so two ids created in the same millisecond still sort in the order they were made. The note under the result says which random source was used, so you can see it rather than take it on trust.

A million, in the format you need

The output format matters more than it sounds. A CSV with a header is what you want for a spreadsheet or a database import. A plain list with no header is what you want for an SQL IN clause, a seed file or a shell loop. JSON and JSON Lines are what a test fixture or a message queue wants.

CSV                 Plain list
id                  9c1f8a2e-4b7d-4a51-9e33-6f0c2d81b4a7
9c1f8a2e-4b7d-...   3e70d5c1-88a2-4f19-b0e4-1a9c7d2e5f38
3e70d5c1-88a2-...   f4a02b93-6c15-4d8e-8b27-9e5a3c0d1f46

Name the column whatever your table calls it, id or order_id or uuid, and the header comes out right so the import needs no mapping step.

When you want more than ids

This page does one column. If what you actually need is a table with ids in it alongside names, emails, dates and money, the full test data generator does that: 33 field types, 8 presets, correlated fields so the email matches the name and the area code matches the city, a seed you can set, and 13 output formats including Parquet and SQLite.

Same million-row ceiling, same in-browser generation, same absence of a sign-up.

Frequently Asked Questions

Are these safe to use as security tokens?

A version 4 UUID has 122 random bits from the browser's cryptographic source, which is more entropy than most session tokens carry, so as a bearer value it is reasonable. A version 7 UUID has 74 random bits plus a readable timestamp, so it is fine as an identifier and worse as a secret. For anything genuinely security-critical, generate the value where it will be used rather than in a web page.

Which version should I pick?

Version 7 for a database primary key, because it sorts by creation time and does not fragment a clustered index. Version 4 for a public identifier or anything where the creation time should not be readable from the id. If you are unsure and it is going in a table, version 7.

What is the row limit?

A million. Not a marketing number: it is the same ceiling the full test data generator uses, and the page really will produce a million rows in your browser. Most tools of this kind stop between five thousand and a hundred thousand. Above a hundred thousand the page warns you that saving the file takes a moment, because it does.

Will they collide?

In any practical sense, no. Version 4 has 122 random bits, which means you would need to generate about a billion a second for eighty-odd years before a collision became likely. Version 7 has 74 random bits per millisecond, which is still far past anything a real system produces in one millisecond.

Can I get the timestamp back out of a version 7 UUID?

Yes, that is the point of the format. The first twelve hex digits, with the dashes removed, are a big-endian Unix millisecond timestamp. Take that as an integer and you have the creation time. It is a feature for debugging and a consideration for privacy.

Why is my browser generating them rather than a server?

Because there is no reason for a server to be involved and several reasons for it not to be. The browser has a cryptographic random source built in, the generation is instant, nothing is transmitted, and there is no queue, no rate limit and no service to be down.

Does anything I paste leave my computer?

No. There is no upload endpoint on this page and no network request in the code that does the work. JavaScript in your own tab reads the text, processes it and hands back the result. Nothing is stored between visits either, so reloading gives you an empty box again. You can confirm it by opening your browser's network panel and watching it stay quiet while you work.

Ids, in bulk, in the right shape

Free, no account, nothing transmitted. Up to a million, five formats, two versions.

Back to the generator