UUID Generator: Make v4 and v7 UUIDs, Then Decode Any UUID

How to use the UUID Generator: Make v4 and v7 UUIDs, Then Decode Any UUID

1. Pick the typeChoose UUID v7 if the values will be database keys or need to sort by creation time. Choose v4 for a plain random identifier. The nil and max UUIDs are special values, all zeros and all ones.
2. Choose how many and in what formatMake one UUID or up to 1,000. The format can be the standard lowercase form, uppercase, with no hyphens, in braces, as a urn:uuid: address, or a short 22-character base64url string.
3. Generate and copyA new UUID is ready as soon as the page loads. Press Generate again for another. A single UUID shows what its bits mean. A batch can be copied as lines, a JSON array, CSV, SQL values, or quoted values, or downloaded as a file.
4. Decode a UUID you already haveOpen the Decode tab and paste any UUID. You get its version, its variant, the time inside it if it has one, and a colored map of every field. A UUID that breaks the standard is flagged with the reason.
5. Find the keys for a time windowOpen the time range tab, enter a start and end time, and copy the smallest and largest v7 UUID that window can contain. Use them in a query to pick rows by creation time.

What a UUID is, and which version to use

A UUID, or universally unique identifier, is 128 bits written as 32 hexadecimal digits in groups of 8, 4, 4, 4, and 12. Microsoft products call the same thing a GUID. Two of those digits carry the version number and the variant, and the rest depend on the version.

RFC 9562, published in 2024, defines eight versions. Only a few matter in practice. Knowing which is which keeps you from using a time-based ID where a random one is needed, or the other way around.

• Version 1 combines a clock reading with a node ID, which was once the machine's network address. It reveals when and where it was made.
• Version 3 and version 5 hash a namespace and a name, so the same input always gives the same UUID. They use MD5 and SHA-1 respectively.
• Version 4 is random. Of its 128 bits, 122 are random and six are fixed for the version and variant. It is the most widely used.
• Version 6 is version 1 with the time fields reordered so that values sort by time.
• Version 7 puts a Unix timestamp in milliseconds in the first 48 bits and fills the rest with random data or a counter. It sorts by time and is the one RFC 9562 steers new database keys toward.
• Version 8 is for custom layouts. What its bits mean is up to whoever defined it.

UUID v7 versus v4

The difference is in the first 12 digits. In a v4 UUID they are random, so a new value lands anywhere in the sort order. In a v7 UUID they are a timestamp, so a new value sorts after the ones made before it. For a database that keeps rows in a B-tree index, new rows then go at the end of the index rather than into the middle of it, which usually means less shuffling of index pages and better use of the cache. How much difference this makes depends on the database and the size of the table, so measure it for your own case before you rely on it.

The price of v7 is that the creation time is visible. Anyone who has a v7 UUID can read when it was made, to the millisecond. For a row ID that is often harmless and sometimes useful. For an identifier that appears in a URL and should not reveal when something was created, use v4. RFC 9562 itself notes that embedded timestamps are a small attack surface and recommends v4 for security uses.

• Choose v7 for primary keys, event IDs, and anything you will later sort or page by time.
• Choose v4 when the ID should reveal nothing, such as a public token-like identifier that is not a secret itself.
• Never treat any UUID as a password or access token. The RFC says implementations should not assume UUIDs are hard to guess.

How the v7 values here stay in order

Many programs make several UUIDs in the same millisecond, and plain random bits would put them in a random order within it. RFC 9562 describes counter methods for this, and this tool uses the first one: the 12 bits right after the version digit hold a counter. When a new millisecond starts, the counter begins at a random value below 2,048, so a busy millisecond has room to count up. Each further value in the same millisecond adds one. The remaining 62 bits stay random.

Two rare cases are handled so that the order never breaks. If more than 4,095 values are needed in one millisecond, the timestamp moves forward by a millisecond, as the RFC suggests handling a full counter. If the device clock steps backwards, new values keep using the latest time already issued instead of an earlier one. In both cases a batch always sorts in the order it was made.

Making v7 UUIDs for a chosen date

Generating for the current time is not always what you need. When you load test data, back-fill rows that existed before you moved to UUID keys, or write a test that depends on ordering, you want values that carry a particular date. Under the options for v7 you can enter a date and time, read in your own time zone or in UTC, and spread a batch over the same millisecond, a millisecond apart, or a second apart.

The time is stored with millisecond precision, from 1970 up to the year 10889, which is as far as 48 bits reach. A value made for 3 October 2026 at 14:15:16.789 UTC decodes back to exactly that moment.

Reading a UUID

The Decode tab accepts a UUID with or without hyphens, in braces, in quotes, with the urn:uuid: prefix, in upper or lower case, or in the 22-character base64url form. It then reports the version digit, the variant, and the time for versions 1, 6, and 7, and colors each field so you can see what is time, what is random, what is a counter, and what is a node ID.

It also tells you when something is off. A UUID whose variant bits are not the standard ones, or whose version digit is outside 1 to 8, still has 32 valid hex digits but does not follow RFC 9562. A version 1 UUID whose node ID does not have the multicast bit set may contain a real network address, which RFC 9562 advises against.

• Version 1 and 6 times count 100-nanosecond steps from 15 October 1582, and the tool converts them to a normal date.
• Version 7 times are Unix milliseconds. The tool shows the date in UTC, in your own time zone, and as time ago.
• Version 4 contains no time at all, so there is nothing to decode apart from the version and variant.
• Version 3 and 5 are hashes. They cannot be turned back into the name that made them.

Querying a time window with v7 keys

Because the time sits at the front of a v7 UUID, a window of time is a range of keys. Every value made in a given millisecond has that millisecond in its first 48 bits, a counter of 0 to 4,095 after the version digit, and random bits at the end. So the smallest possible value for the millisecond has a counter and random bits of all zeros, and the largest has them all set to one.

The time range tab builds those two bounds for your start and end times, and writes the condition for you. This lets a query use the primary key index instead of a separate created-at column. It works where UUIDs compare in byte order, such as PostgreSQL's uuid type and MySQL or MariaDB with BINARY(16). It does not work in SQL Server, which compares uniqueidentifier values starting from the last group, as Microsoft engineer Raymond Chen documents. Keep in mind too that the time inside a UUID is set by the program that made it, so it can differ slightly from the moment the row was saved.

Formats, GUIDs, and byte order

The same 128 bits can be written several ways. RFC 9562 allows upper or lower case when reading, and the examples it shows are lowercase, so lowercase is the safe choice for output. Some systems want no hyphens, braces, or a urn:uuid: prefix, and a 22-character base64url form is handy in URLs and short codes.

A GUID in .NET or SQL Server is the same 128 bits, but its in-memory byte layout swaps the order of the first three groups. A call such as Guid.ToByteArray() gives bytes in that order, which is not the order of the text. The Decode tab shows the swapped bytes for any UUID, so you can compare it with what you see in a debugger or a database dump.

How likely is a duplicate?

For v4, the chance that two values match follows the birthday problem. With 122 random bits, you would need about 2.7 quintillion values, 2 raised to the 61st power, before the chance of any pair matching reaches about 39 percent. Even a billion UUIDs gives odds of roughly one in ten quintillion. The built-in odds panel does this arithmetic for any number you enter.

These odds assume a good source of randomness. This tool takes its random bits from the browser's cryptographic generator, crypto.getRandomValues, which is designed for exactly this. The chance of a clash is far smaller than the chance of a bug in the code that stores the IDs, so spend your effort there.

Limits and accuracy

• It generates UUID v4, UUID v7, and the nil and max UUIDs. It reads versions 1 to 8, but it does not generate v1, v3, v5, v6, or v8.
• The time in a v7 UUID comes from this device's clock. If the clock is wrong, the time inside the UUID is wrong too.
• Order is guaranteed within one batch, and across batches from the same page while it stays open. Values made at the same moment in two tabs or on two computers do not sort in a guaranteed order within that millisecond.
• A batch holds up to 1,000 values. For many more, generate in your own code or use your database's functions.
• A UUID is an identifier, not a secret. Do not use one as a password, an API key, or an access token.
• Range bounds are only useful where UUIDs compare in byte order. They do not work for SQL Server's uniqueidentifier type.
• Decoding shows what a UUID encodes. It cannot prove who made it, or that the embedded time is the true time.

Frequently asked questions