UUID Generator

2026-10-17

Generate random UUID v4 or time-ordered UUID v7 in bulk, from 1 to 1000 at a time, in the format you need. Copy one value or the whole list, download it as a text file, and decode any UUID to see its version, variant and embedded timestamp.

How to use the UUID generator

1. Choose the version. UUID v4 is random. UUID v7 starts with the current time, so newer values sort after older ones.
2. Set how many UUIDs you want, from 1 to 1000. The list updates as soon as you change the version or the number.
3. Pick a format: standard lowercase, uppercase, without hyphens, in braces, as a urn:uuid: URN, or Base64. Changing the format rewrites the same UUIDs; it does not draw new ones.
4. Use Copy next to one UUID, Copy all for the whole list (one per line) or Download .txt to save it. Generate new draws a fresh set.
5. To inspect a UUID, paste it into the decoder. It tells you whether the value is valid, its version and variant, and, for versions 1, 6 and 7, the time stored inside it.

How it works

A UUID (universally unique identifier) is a 128-bit number, normally written as 32 hexadecimal digits in groups of 8-4-4-4-12. Two small fields describe the rest: the 4-bit version is the first digit of the third group, and the variant is stored in the top bits of the first digit of the fourth group. For the standard variant that digit is 8, 9, a or b. The standard is RFC 9562, published in 2024, which replaced the older RFC 4122.

UUID v4 is 122 random bits plus the version (0100) and variant (10) bits. The page takes the random bits from the browser's cryptographically secure generator: crypto.randomUUID() when the browser provides it, otherwise crypto.getRandomValues(). If neither exists, the page says so instead of falling back to a weak generator.

UUID v7 puts a timestamp first, so the values sort in creation order:

When several UUIDs are made in the same millisecond, the 12-bit counter in rand_a goes up by one each time, so the list is strictly increasing. For each new millisecond the counter starts from a random value below 2048, which leaves room to count. If the counter ever ran out, or the system clock stepped backwards, the generator would move the timestamp forward by one millisecond rather than repeat or go out of order. The counter lives in the open page, so two tabs or two computers order their values by millisecond only; the 62 random bits keep them from colliding.

The decoder reads time as follows. In v7 it is the first 48 bits as Unix milliseconds. In v1 and v6 it is a 60-bit count of 100-nanosecond intervals since 15 October 1582, stored in a different bit order in each version. The tool subtracts 122,192,928,000,000,000 intervals (the gap between 1582-10-15 and 1970-01-01) and divides by 10,000 to get Unix milliseconds. The nil UUID is all zeros and the max UUID is all ones; both are recognised and have no version.

Examples

Example 1: a v7 UUID. Decode 017F22E2-79B0-7CC3-98C4-DC0C0C07398F. The third group starts with 7, so the version is 7. The fourth group starts with 9 (1001), so the variant bits are 10, the standard variant. The first 48 bits, 017F22E279B0, equal 1,645,557,742,000 ms, which is 2022-02-22T19:22:22.000Z.

Example 2: a v1 UUID. Decode C232AB00-9414-11EC-B3C8-9F6BDECED846. The version is 1. Joining the time fields in the order high, mid, low gives 1EC9414C232AB00, which is 138,648,505,420,000,000 intervals. Subtracting the 1582-to-1970 offset leaves 16,455,577,420,000,000 intervals, or 1,645,557,742,000 ms, and the tool shows 2022-02-22T19:22:22.0000000Z, the same instant as example 1.

Example 3: a v6 UUID. 1EC9414C-232A-6B00-B3C8-9F6BDECED846 holds the same time as example 2 with the fields reordered so that it sorts by time. The version is 6 and the decoded time is again 2022-02-22T19:22:22.0000000Z.

Example 4: special values. 00000000-0000-0000-0000-000000000000 is reported as the nil UUID and ffffffff-ffff-ffff-ffff-ffffffffffff as the max UUID. Neither is given a version or a timestamp.

UUID v4 or v7 for database keys

Both versions can be created anywhere without asking a central server for the next number. The difference shows up in database indexes. Random v4 keys land at arbitrary places in an ordered index, so inserts touch many different pages, the pages split, and a big table stops fitting in memory. Time-ordered v7 keys arrive in roughly increasing order, so new rows are added near the end of the index, much like an auto-incrementing number, while the key is still globally unique.

The price of v7 is that the ID shows when the row was created, to the millisecond, to anyone who can see it. That is fine for an order number or a log entry and unwelcome where creation time is private. v4 reveals nothing and is the safer choice for identifiers that are exposed publicly and have no need to sort. Neither is a secret: for password-reset links or API tokens, use a purpose-built random token of sufficient length.

Common mistakes to avoid:

• Comparing UUIDs as case-sensitive text. Upper and lower case denote the same value.
• Storing them as long strings when the database offers a 16-byte type, which halves the index size.
• Expecting v7 order across machines. Clocks differ, so order is only approximate between different generators.
• Sorting Base64 text and expecting time order. The Base64 alphabet is not in ASCII order, so only the hexadecimal forms sort by time.

Frequently asked questions

Can two UUID v4 values be the same?

In theory yes, in practice no. With 122 random bits, you would need to generate roughly 2.7 quintillion (2.7 × 10¹⁸) values before the chance of any duplicate reached 50%.

What is the difference between a UUID and a GUID?

They are the same 128-bit format. GUID is the name some platforms use, often written in uppercase with braces, which is why those formats are offered here.

Can I sort UUID v7 values as text?

Yes, in the standard, uppercase or no-hyphen formats, as long as the case is the same. The timestamp comes first in fixed-width hexadecimal, so alphabetical order equals time order.

Does a v4 UUID contain a date?

No. Only versions 1, 6 and 7 carry a timestamp, and the decoder shows one only for those. Versions 3 and 5 are hashes of a name, 4 is random, and 8 is left to the generator's design.

What does the decoder accept?

Any UUID in standard form with or without hyphens, in upper or lower case, in braces, or with the urn:uuid: prefix, plus the 24-character Base64 text this page produces. Anything else gets an explanation of what is wrong.

Is anything uploaded or stored?

No. Generation and decoding run entirely in your browser and nothing leaves your device. Your choices (version, count, format and the decoder text) are saved only in this browser's local storage, never the generated UUIDs.

Related tools

• JSON Formatter — format and validate JSON that carries your IDs.
• Regex Tester — test patterns that match UUIDs in logs and text.
• CSV to JSON Converter — turn tables of records into JSON.
• List Compare — find which IDs appear in one list but not another.
• Two's Complement Calculator — work with binary numbers and bit patterns.
• Subnet Calculator — another everyday tool for working with identifiers and addresses.