UUID & ULID Generator
UUID generator for v4, v7 and ULID, up to 1000 ids per press. v4 is 122 random bits; v7 and ULID sort by creation time.
Generated
Minting some ids
- Choose a Format. UUID v4 (random) is preselected, with UUID v7 (time-ordered) and ULID (sortable) beside it. Changing it refills the list straight away.
- Put your count in How many, anything up to 1000. The list refills one id per line as you type, and Generate again draws a fresh batch with the same settings.
- Take the lot with Copy all, or one id with the copy button on its line. Download .txt saves a batch of two or more as a file.
About this tool
Ask a UUID generator for a value and what comes back is 128 bits printed as 32 hex digits in that 8-4-4-4-12 grouping everyone recognises. GUID is Microsoft's word for the same object. The Format dropdown carries three of them. UUID v4 is where you land, and one is already on the page when it opens. It is pure randomness apart from six bits that pin down the version and variant, leaving 122 to draw. That works out to roughly 5.3 x 10^36 possible values, which is the reason nobody has to coordinate who hands them out.
UUID v7 and ULID both open with a 48-bit millisecond timestamp, so a run of them sorts in the order it was made. Database people care about that: a v4 primary key scatters inserts across the index, while a v7 key keeps appending at the right-hand edge. v7 comes from RFC 9562 and keeps the hyphenated hex shape, so anything already parsing a UUID swallows it unchanged. ULID states the same idea in 26 characters of uppercase Crockford base32 with no hyphens, and that alphabet drops I, L, O and U so nothing gets misread when a person retypes it.
Values are drawn from crypto.getRandomValues, not Math.random, which is the gap between an id you can publish and one somebody can guess from the two before it. How many takes up to 1000 at once, which covers seeding a fixtures file or filling a test table, and Download .txt saves a batch that size as a file rather than sending it through the clipboard. UUIDs come out lowercase and ULIDs uppercase, since that is what each spec calls canonical.
Two hundred order ids for a fixtures file, minted at half past nine
A test database wants 200 orders with keys that will sort the way real orders do, so switch Format to UUID v7, type 200 into How many and the list refills as you type. Every line opens with the same thirteen characters, 01a06174-31c0, because that is the hex of the millisecond the batch was minted: 09:30:00 UTC on 2 September 2026. The three characters after the version digit 7 count up within each millisecond, 000, 001, 002, so the file sorts in exactly the order the ids were made; the random tail after them keeps any two apart.
Switch to ULID and the list refills without another press. Now the same moment reads 01M1GQ8CE0 across the first ten characters. The sixteen after them are random on the first line and one higher on every line below it, which is how the ULID spec keeps a single millisecond in order. Whichever you paste into the fixtures file, a query ordered by that key returns the rows in the order you generated them, which is the property a random v4 key cannot offer. Paste one back into Read one back and it names the millisecond and its place in the batch.
Good to know
- v1, v3 and v5 are missing. v1 bakes in a MAC address and a clock, and the name-based pair need a namespace and a string that there is nowhere to type here.
- v7 and ULID wear their creation time in the leading characters, so whoever holds one can read off roughly when it was minted.
- Uniqueness is a probability, never a registration. Nothing checks a value against any list; the odds are just long enough that collisions stop being worth worrying about.
Frequently asked questions
What is the difference between a UUID and a GUID?
None that matters. GUID is the name Microsoft used, UUID is the name in the RFC, and both describe the same 128-bit value in the same 8-4-4-4-12 hex layout. Code that reads one reads the other.
Could two of these ever collide?
In theory, and pretty much only in theory. A v4 carries 122 random bits, so you would be minting billions a second for longer than anyone plans to run a system before a duplicate showed up. v7 and ULID share a timestamp when they are made in the same millisecond, and the random tail underneath still keeps them apart.
Is a v4 UUID safe to put in a public URL?
It gives nothing away, because those 122 bits come from a cryptographically secure source and encode no timestamp, counter or machine detail. It is still just an identifier. Anyone who sees it can replay it, so keep a real session check in front of whatever the id points at.
Which format should I use for a primary key?
v7 for most tables. It sorts by creation, so new rows land at the end of the index instead of scattering through it, and it still fits any column already typed as a uuid. Pick ULID when the id ends up in a URL or gets read aloud, and v4 when you would rather the row's creation time stayed private.
How do I read the creation time back out of a v7 UUID?
Take the first twelve hex digits, ignoring the hyphen, and treat them as a number of milliseconds since 1970. For 01a06174-31c0-7d3e-ba54-03ac8e6f5abb that is 01a0617431c0, which is 1788341400000 in decimal, which is 09:30:00 UTC on 2 September 2026. A ULID does the same job with its first ten characters, read as base32 in the Crockford alphabet. Or paste either into Read one back and the page does the arithmetic.
Why does How many refuse a number I typed?
The count has to be a whole number from 1 to 1000; a blank box, 0, 1001 and 2.5 all miss. The field turns red and says so, and the ids you already had stay on the page, dimmed, under a line saying they belong to the last count that worked. Fix the number and a new batch replaces them.
How much of a v7 or ULID is actually random?
Less than a v4, and by a known amount. A v7 spends 48 bits on the timestamp and 6 on version and variant, which leaves 74; this page spends 12 of those on a counter that keeps one millisecond's ids in order, so 62 are random. A ULID carries a 48-bit timestamp in its first ten characters and 80 random bits in the other sixteen, but only the first ULID of a millisecond draws them: each one after it in that millisecond is the one before plus one, which keeps the batch in order and makes the next id easy to guess. Both formats keep ids made in the same millisecond distinct; neither is a substitute for a secret.
Missing something in UUID & ULID Generator? Suggest a feature →
Tell someone who needs this.