Values come from the browser cryptographic random number generator and are never reused or logged.
Generating one identifier is trivial. Generating a batch in the right format for the place you are about to paste it is the part that wastes time — reformatting a list of UUIDs into a SQL IN clause or a JSON array by hand is exactly the kind of work that introduces a typo. This tool produces the values and the wrapper together.
It covers the formats that actually come up: UUID versions 4 and 7, ULID, a Nanoid-style short identifier, plain hex, and a numeric form. Every value comes from the browser cryptographic random number generator.
How to use this tool
- Choose how many identifiers you need and which format you want. Values appear immediately — there is no generate-then-copy round trip for the first batch.
- Press Generate again for a fresh batch at any time. Nothing is stored between batches, so a previous set is not recoverable once replaced.
- Click any individual value to copy just that one. Each click flashes to confirm, so you are not left guessing whether it worked.
- Use Copy all for a plain list, Copy as JSON array for a javascript or JSON context, or Copy as SQL IN list for a database query. The formatting is done for you, which removes the paste-then-edit step.
v4 versus v7: the choice that actually matters
Version 4 is what most people mean by a UUID. It is 122 bits of randomness with six bits reserved to mark the version and variant, which is why a v4 UUID looks entirely arbitrary. Version 7 was standardised later and rearranges the same 128 bits so the first 48 bits are a millisecond timestamp, with the remainder random.
The practical difference is index locality in a database, and it is not a small effect.
A primary key is normally a B-tree index. Inserting a v4 key places the new row at a random point in that tree, so as the table grows, the pages being written are scattered across the whole index. Each insert may touch a page that is not in the buffer pool, causing a disk read and a page split, and the working set that has to stay cached grows with the table. At a few million rows this becomes visible; at a few hundred million it is the dominant cost.
A v7 key begins with a timestamp, so successive inserts sort close to each other and land on pages that are already in memory. Insertion stays effectively append-only in the same way a sequential integer key does, while keeping the properties of a UUID: globally unique without coordination between nodes, and safe to expose because it does not reveal a row count.
The trade is that a v7 UUID discloses when it was created to anyone holding it. For most applications that is harmless, and is arguably useful for debugging. It is unacceptable in a small number of cases, and for those, v4 or a random opaque identifier is correct.
Worth noting: this difference matters for identifiers being written, not for ones being read. If you are generating values for an API request or a test fixture, the choice is irrelevant. If you are choosing the primary key type for a new table, it is one of the more consequential schema decisions available to you.
How random is random, and why the source matters
Not all randomness is equal, and using the wrong kind for identifiers is a real class of vulnerability.
JavaScript offers Math.random(), which is fast and entirely unsuitable here. It is a seeded pseudo-random generator, and the algorithm and seed can be recovered from a modest number of observed outputs. Anything generated with it is predictable to someone who has seen earlier values. It is fine for a visual effect and unfit for a credential, a password reset token or a session identifier.
crypto.getRandomValues() is the browser cryptographic generator, seeded from the operating system entropy pool. Its output is not predictable from previous outputs. This tool uses it for every format.
Two caveats still apply, and it is worth understanding both. First, generation happens in the browser, so the quality of the randomness depends on the device. A poorly seeded virtual machine is a known weakness of the environment, not of the generator. Second, and more importantly, this tool is not a security boundary: if you need tokens for authentication, generate them server-side where the entropy source is under your control.
The formats, and when each is the right one
- UUID v4 — the default choice for an identifier with no ordering requirement. 36 characters with hyphens, 32 without. Universally supported by databases, languages and libraries.
- UUID v7 — time-ordered. Use for database primary keys, and for any identifier you want to sort roughly chronologically without storing a separate timestamp column.
- Uppercase and no-dash variants — cosmetic, but some systems are strict. Oracle and a few enterprise tools have historically expected uppercase; some compact serialisations drop the hyphens. Both refer to exactly the same value.
- Braced form — curly braces around a UUID, as used in some Microsoft and .NET contexts, and in a few Windows registry and COM interfaces.
- ULID — 26 characters in Crockford base32. It carries a 48-bit timestamp like v7, but is case-insensitive and dictionary-sortable, which makes it easier to read aloud and to use in filenames and URLs where a hyphen is unwelcome.
- Short ID — 21 characters, like the Nanoid convention. Useful where a full UUID is longer than the context justifies: URL slugs, short links, public-facing identifiers.
- Hex 32 — a UUID with no hyphens, in the raw hexadecimal form. Convenient as a fixed-width file or column name.
- Numeric 18 digits — a large decimal integer. Suitable for systems that require a numeric key, though with far less randomness than a UUID: roughly 60 bits, so collisions are possible at very large scale.
Whichever you choose, convert once and store consistently. Storing the same logical identifier in two formats in different tables is a reliable source of join failures.
Collision probability, in numbers
People reasonably want to know how much to trust a random identifier, and the answer is a specific figure rather than a reassurance.
A v4 UUID carries 122 random bits. By the birthday bound, you reach a fifty per cent chance of any collision somewhere around 2.7 x 10^18 values — generated randomly, with no coordination. For perspective, generating a billion UUIDs per second would take roughly eighty-five years to reach that point.
The probability in any realistic scenario is far smaller than the probability of the hardware storing them failing. Treating v4 as unique without a uniqueness check is standard and reasonable practice.
Two situations do warrant care. A generator using a weak entropy source can repeat values far sooner than the maths suggests — this is why browser-based generation is fine for identifiers and inappropriate for secrets. And a truncated identifier has correspondingly fewer bits: take a v4 UUID and keep only the last eight characters and you have 32 bits, where a collision becomes likely after only around sixty-five thousand values.
This tool also guarantees uniqueness within a single batch, so asking for a hundred values cannot return a duplicate even in principle.
Putting a batch to work
The copy formats exist to remove the reformatting step, and the typical uses are routine:
- SQL IN list — fetching a set of rows by identifier. Paste the list straight into a
WHERE id IN (...)clause. - JSON array — seeding a fixture file, a test payload, or a request body that expects a collection of identifiers.
- One per line — a file to feed into
xargsor a shell loop, or a column to paste into a spreadsheet.
Two safety notes. Treat a generated batch as disposable once you navigate away — nothing is persisted, so regenerate rather than hunting for a value you saw earlier. And do not use these values for secrets. An API key, a password reset token or a session identifier needs server-side generation and, in most designs, more considerations than randomness alone.
If you are generating an identifier to test a decoder elsewhere, the UUID Generator pair to have open is the JWT Decoder for token work and the Timestamp Converter if you want to confirm that a v7 value embeds the time you expect.
Choosing a format
| Use case | Format | Why |
|---|---|---|
| Database primary key on a new table | UUID v7 | Time-ordered, so inserts stay local to the index instead of scattering |
| Identifier that must not reveal creation time | UUID v4 | Fully random, no timestamp embedded |
| Test fixtures and seed data | UUID v4 | Widely supported by every ORM and language |
| Short link or public URL slug | Short ID (21 chars) | Shorter than a UUID and URL-safe without hyphens |
| Filename or sortable list | ULID | Case-insensitive, dictionary-sortable, no punctuation |
| Legacy .NET or Oracle column | UUID v4 uppercase or braced | Matches the convention those systems expect |
| A system that only accepts integer keys | Numeric (18 digits) | Numeric, though with fewer random bits than a UUID |
| Fixed-width file column | Hex (32 chars) | Constant length with no separators |