UUID Generator
Create random or time-ordered identifiers in bulk, format them for JSON, CSV or a SQL insert, and paste any existing id to find out which version it is and when it was made.
1 to 1,000.
🎨 Formatting
📦 Result
How to use the UUID generator
- Pick the identifier type: v4 for pure randomness, v7 for time-ordered ids, ULID for a shorter sortable form, or nil for the all-zero placeholder.
- Set how many you need, from 1 to 1,000. The batch regenerates whenever you change an option, or press 🎲 Generate for a fresh set.
- Switch on the formatting you want — uppercase, braces or hyphens removed — and choose an output format: plain lines, a JSON array, CSV with a header, or a ready-to-run SQL
INSERT. - Press Copy all or Download to take the whole batch, not just what fits on screen.
- Switch to the 🔍 Inspect tab and paste any id to see its version, variant and, for v1, v6, v7 and ULID, the exact moment it was created.
How each format is built
A UUID is 128 bits, written as 32 hexadecimal digits in a 8-4-4-4-12 grouping. Six of those bits are fixed: four for the version, two for the variant.
| Type | Time bits | Random bits | Sortable | Length |
|---|---|---|---|---|
| UUID v4 | 0 | 122 | ❌ no | 36 characters |
| UUID v7 | 48 (ms) | 74 | ✅ yes | 36 characters |
| ULID | 48 (ms) | 80 | ✅ yes | 26 characters |
| Nil | 0 | 0 | — | 36 characters |
v4 fills all 16 bytes from the cryptographic random generator, then overwrites the version nibble with 4 and the top two bits of byte 8 with binary 10.
v7 follows the RFC 9562 layout exactly: bytes 0–5 hold the Unix timestamp in milliseconds as a big-endian 48-bit integer, byte 6 holds the version nibble plus four random bits, byte 8 holds the variant bits plus six random bits, and bytes 9–15 are random. Sorting the text form therefore sorts by creation time.
ULID encodes the 48-bit timestamp as 10 Crockford Base32 characters followed by 16 characters of randomness, giving 26 characters that also sort as text.
Worked examples
Reading a v7 id. Paste 017f22e2-79b0-7cc3-98c4-dc0c0c07398f into the inspector. The first 12 hex digits, 017f22e279b0, are 1645557742000 in decimal — 22 February 2022 at 19:22:22 UTC. The 7 at position 13 is the version, and the 9 at position 17 confirms the RFC variant. This is the example identifier from RFC 9562 itself.
Reading a v4 id. 919108f7-52d1-4320-9bac-f847db4148a8 shows version 4 and variant RFC, with no timestamp — there is nothing in it but randomness and the six fixed bits.
Reading a ULID. 01ARYZ6S41TSV4RRFFQ69G5FAV decodes its first 10 characters to 1469918176385, which is 30 July 2016. The remaining 16 characters are the random part.
Bulk insert. Choose v7, set the count to 500, pick the SQL output and set the table to orders and the column to id. You get a single INSERT INTO orders (id) VALUES statement with 500 rows, each one millisecond apart so the order is preserved exactly.
Tips and common mistakes
- Store UUIDs as 16 bytes, not 36 characters. PostgreSQL has a native
uuidtype and MySQL hasBINARY(16). Storing the text form more than doubles the space and slows every index lookup. - Do not sort v4 ids and expect chronology. They are random; any apparent ordering is coincidence.
- Hyphens are presentation only.
919108f752d143209bacf847db4148a8and the hyphenated form are the same value. Normalise before comparing. - Braces come from Windows. The
{…}GUID form appears in the registry and in COM code; most other systems reject it. - Case is not significant for UUIDs, but it is conventional to store them lowercase. ULIDs, by contrast, are canonically uppercase.
- v7 within the same millisecond is not guaranteed to sort correctly unless the generator adds a counter. This tool advances the timestamp by one millisecond per id in a batch, so a batch is always strictly increasing.
Glossary
- Variant – the two or three bits that say which UUID specification the layout follows; RFC 9562 uses
10. - Version – the four bits that say how the rest of the bits were derived: random, hashed, or time-based.
- Crockford Base32 – a 32-character alphabet that omits I, L, O and U to avoid transcription errors.
- Monotonic – guaranteed to increase; useful when ids double as an ordering key.
Privacy
Every identifier on this page is produced inside your browser tab using crypto.getRandomValues, and the inspector parses whatever you paste with local JavaScript. No id is transmitted, none is written to storage or a cookie, and there is no server component that could keep a copy. That matters more than it sounds: a UUID often is the secret — a password-reset token, an invite link, a signed-URL key — so pasting one into a hosted validator is a genuine leak. Here, closing the tab is the end of it.
Frequently asked questions
Should I use UUID v4 or v7?
Use v7 for anything that becomes a database primary key. Because the first six bytes are a millisecond timestamp, new rows land at the end of the index instead of scattering across it, which keeps inserts fast and the index compact. Use v4 when the identifier is public and the creation time should stay private.
Can two UUID v4 values collide?
In practice, no. v4 carries 122 random bits, so you would need to generate about 2.7 quintillion of them before the chance of a single collision reaches 50 percent. The realistic risk is a weak random source, not the maths — which is why this tool uses crypto.getRandomValues.
What is a ULID and how is it different?
A ULID stores the same 48-bit millisecond timestamp plus 80 random bits, but encodes all of it in 26 Crockford Base32 characters instead of 36 hex characters and hyphens. It sorts lexicographically, it is case-insensitive, and the alphabet leaves out I, L, O and U so it cannot be misread aloud.
What are the version and variant fields?
The 13th hex digit is the version, and the top bits of the 17th are the variant. The variant says which specification the layout follows, and RFC 9562 UUIDs always start that byte with binary 10, which is why the 17th character is always 8, 9, a or b.
Is the nil UUID a valid identifier?
It is valid but it means "no value". Storing it in a column that should hold a real id is almost always a bug that slipped through a default value or an uninitialised variable, so the tool shows a warning when you generate it.
Does a v7 UUID leak information?
Yes, and deliberately so. Anyone holding the id can read the millisecond it was created, which reveals sign-up times, order times and creation rates. If that matters, use v4 for anything exposed to users and keep v7 internal.
Related tools
- Password GeneratorBuild a random password or a memorable passphrase with real cryptographic randomness. Entropy, strength and crack time are shown for the exact options you picked — and nothing ever leaves your browser.
- Hash GeneratorCompute SHA and CRC32 digests of text or files entirely in your browser, switch between hex and Base64, sign messages with HMAC, and check two hashes against each other.
- Unix Timestamp ConverterA live epoch clock, instant timestamp-to-date conversion in UTC and your local time, a date-to-timestamp direction, and a batch mode for whole log columns.
- JSON Formatter & ValidatorPaste JSON, get it beautified, minified or validated with the exact line and column of the problem. Everything runs in your browser.
- Cron Expression GeneratorWrite a cron expression in Unix, Spring or Quartz form, read what it actually means in English, and see the next ten fire times in UTC and your local time.
- Base64 Encoder & DecoderConvert text, files and data URIs to and from Base64 with correct UTF-8 handling, a URL-safe option and MIME line wrapping. Nothing is uploaded.
Last reviewed: