UUID Generator — v4, v7, ULID and NanoID, With Decoder
Generate UUID v4 or time-ordered v7, ULIDs and NanoIDs in bulk, or paste an ID to see its version and embedded timestamp.
Validate and decode an ID
UUID version 7 (Unix-time-ordered)
| Canonical | 017f22e2-79b0-7cc3-98c4-dc0c0c07398f |
|---|---|
| Version | 7 — Unix-time-ordered |
| Variant | RFC 9562 / RFC 4122 |
| rand_a (12 bits) | cc3 |
| Timestamp | 2022-02-22T19:22:22.000Z Unix ms 1645557742000 |
IDs are generated in your browser with crypto.getRandomValues. Nothing is sent or stored. Browse all free tools.
Found a problem, or something that could be better? We read every message and we fix things quickly.
This UUID generator creates random version 4 UUIDs, time-ordered version 7 UUIDs as defined in RFC 9562, ULIDs and NanoIDs, one at a time or up to 10,000 in a batch you can copy or download. Every random bit comes from crypto.getRandomValues, the browser's cryptographic generator, not Math.random. The decoder below takes any UUID, GUID or ULID and tells you its version and variant, and for v1, v6, v7 and ULID, the moment it was created.
Version 7 and ULIDs from one batch are strictly increasing, even when thousands share the same millisecond, so they sort in creation order as database keys should. Version 1 is not offered: a browser has no access to a MAC address or a persistent clock sequence, so a v1 UUID made in a web page would only imitate the format. If you need v1 or name-based v3/v5 UUIDs, generate them in your language's UUID library.
How to use
- Pick the type: v4 for a general-purpose random ID, v7 for database primary keys, ULID or NanoID if your stack uses them.
- Set how many you need, up to 10,000, and press Generate (or Enter in the count field).
- Choose a format: uppercase, without hyphens, or wrapped in braces for Windows registry and .NET contexts.
- Copy all, or download as a text file with one ID per line, or as a JSON array.
- To inspect an existing ID, paste it into the decoder to see its version, variant and any timestamp it carries.
Frequently asked questions
What is the difference between UUID v4 and v7?
A v4 UUID is 122 random bits with no structure. A v7 UUID puts a 48-bit Unix timestamp in milliseconds at the front, followed by 74 random bits, so v7 values sort by creation time. That ordering makes v7 much friendlier as a database primary key: new rows go to the end of the index instead of random positions, which reduces page splits and keeps inserts fast. The trade-off is that a v7 ID reveals when it was created.
Can two UUIDs ever be the same?
In theory yes, in practice no, provided they come from a good random source. With 122 random bits, you would need to generate about 2.7 quintillion (2.7 × 10^18) v4 UUIDs to reach a 50% chance of a single collision. Real duplicates come from bugs: a weak or badly seeded random generator, copied virtual machine state, or code that reuses a value.
Is a GUID the same as a UUID?
Yes. GUID is Microsoft's name for the same 128-bit identifier, and modern GUIDs are standard UUIDs (usually version 4). The only differences are presentation: Windows tools often show GUIDs in uppercase and wrapped in braces, like {3F2504E0-4F89-41D3-9A0C-0305E82C3301}. Use the uppercase and braces options to match that form.
Should I use UUID v7 or ULID?
Both are 128-bit, time-ordered and carry a millisecond timestamp. UUID v7 fits anywhere a UUID column or type already exists, such as PostgreSQL's uuid type or Java's UUID class. ULID is shorter as text (26 characters instead of 36) and case-insensitive, but needs its own library and is stored as text or binary. If your database and language already speak UUID, v7 is the simpler choice.
How long should a NanoID be?
The default 21 characters from the 64-character URL-safe alphabet gives 126 bits of randomness, comparable to UUID v4's 122. Shorter IDs are fine when the number of IDs is small and guessing one is harmless, such as a short link with rate limiting. The bit count shown under the length slider tells you what you are trading away; each character from a 64-symbol alphabet adds 6 bits.
Can I tell when a UUID was created?
Only for time-based versions. Paste the ID into the decoder: v7 and ULID store Unix milliseconds in their first 48 bits, and v1 and v6 store 100-nanosecond intervals since 15 October 1582. A v4 UUID contains no time at all, only random bits plus the version and variant markers.
Reading a UUID: version and variant
A UUID is written as 32 hex digits in groups of 8-4-4-4-12. Two positions identify it. The first digit of the third group is the version: in 0190a3c4-1b2c-7d3e-8f40-0123456789ab it is 7. The first digit of the fourth group encodes the variant: 8, 9, a or b means the standard RFC 9562 layout, which is what nearly every UUID today uses.
• v1: Gregorian timestamp plus the generating machine's MAC address. Leaks both; rarely used for new systems.
• v3 and v5: deterministic, derived from a namespace and a name with MD5 (v3) or SHA-1 (v5). The same input always gives the same UUID.
• v4: random. The default for most libraries.
• v6: v1 with the timestamp reordered so it sorts; a migration path for v1 users.
• v7: Unix-millisecond timestamp plus random bits. The recommended time-ordered version for new systems.
• v8: a vendor-defined layout; only the version and variant bits are fixed.
Why random UUIDs slow databases down, and what v7 fixes
Most databases store a primary key in a B-tree index. With sequential keys, each new row lands on the rightmost page of the index, which stays in memory. With random v4 UUIDs, each insert lands on a random page; once the index is larger than memory, inserts start reading pages from disk and splitting them, and write throughput drops. MySQL's InnoDB, which clusters the whole table by primary key, feels this most.
UUID v7 keeps the benefits of UUIDs (globally unique, can be generated by any client without a round trip, safe to expose) while behaving almost like an auto-increment column in the index. RFC 9562, published in May 2024, recommends v7 over v1 and v6 for new time-based IDs, and PostgreSQL 18 added a built-in uuidv7() function.
Store UUIDs in a native 16-byte type (uuid in PostgreSQL, BINARY(16) in MySQL) rather than a 36-character string, which more than doubles index size.
UUID vs ULID vs NanoID at a glance
• UUID v4: 36 characters, 122 random bits, universal library and database support, not sortable.
• UUID v7: 36 characters, 48-bit millisecond time plus 74 random bits, sortable, supported wherever UUIDs are.
• ULID: 26 characters of Crockford Base32, 48-bit time plus 80 random bits, sortable and case-insensitive, needs a library.
• NanoID: 21 characters by default, any alphabet and length, URL-safe and compact, no timestamp and no standard binary form.
Related free tools
- Unix Timestamp Converter — Convert epoch seconds, milliseconds, microseconds or nanoseconds to dates in any time zone, and back. Live clock, batch mode, code snippets.
- Password Generator — Generate a strong random password, a memorable passphrase or a PIN. Runs entirely in your browser, nothing is sent or stored.
- Hash Generator — Hash text or files with MD5, SHA-1, SHA-256, SHA-384, SHA-512 and CRC32, verify a checksum, or compute an HMAC. Files never leave your device.
- JSON Formatter — Pretty-print, minify and validate JSON, with parse errors located by line and column. In your browser, no upload.