UUID v7 Generator: Practical Tips and Common Mistakes
Reviewed by the OnlineFree.app team · Updated
Key points
- UUID v7 stores a 48-bit millisecond timestamp first, so values sort in creation order as plain text.
- The generator clamps the count to 1–1000 and falls back to 10 on non-numeric input, silently.
- Uppercase and hyphen toggles change only the string, never the underlying 128-bit value.
- UUID v7 is sortable but not strictly monotonic, because values in the same millisecond differ only by random bits.
- A v7 reveals its creation time to the millisecond, so avoid it for public-facing identifiers.
What is a UUID v7?
A UUID v7 is a 128-bit identifier defined in RFC 9562 whose first 48 bits hold a Unix timestamp in milliseconds, which makes new values sort after older ones in plain text order. The UUID v7 Generator builds these values in your browser and returns them as a copyable list, with no install and no sign-up.
The layout is fixed: 48 bits of millisecond timestamp, a 4-bit version nibble set to 7, 12 bits of rand_a, a 2-bit variant field, and 62 bits of rand_b. That leaves 74 random bits per value, packed into a 128-bit number.
Compared with v4, which spends all 122 non-version bits on randomness and does not sort, v7 trades randomness for ordering. That is the whole point: index locality in a database. The format itself is specified in RFC 9562, and the general background on the 128-bit format is covered on Wikipedia.
We generated a batch while writing this and the values came back oldest-first, one per line. The first 12 hex characters encode the timestamp, so if you watch that group across two batches generated a second apart, it visibly grows.
Uppercase, hyphens, and the 32-character form
The tool has exactly three controls, and two of them change the string, not the value. Uppercase is off by default, so you get 018f2c9e-... rather than 018F2C9E-.... Hyphens are on by default, producing the canonical 36-character form; turning them off returns the 32-character compact form used in URLs and storage keys.
A common mistake is mixing the two forms in the same column. PostgreSQL's uuid type accepts uppercase on input and normalizes it to lowercase on output, so pasting uppercase is harmless there. But if you store the string in a text or CHAR(36) column with a case-sensitive collation, 018F2C9E-... and 018f2c9e-... are different keys and you can insert what is semantically the same identifier twice.
The compact 32-character form is not accepted everywhere. SQL Server's uniqueidentifier type expects the hyphenated form, and some ORM migrations compare literal strings against a schema that assumes hyphens. If you are unsure, leave the hyphens toggle on and convert downstream.
One detail worth repeating: the toggles only affect presentation. A UUID with hyphens removed is the same 128-bit value, not a different one.
How many UUIDs should you generate at once?
The count field accepts integers from 1 to 1000 and clamps silently to the nearest bound. Type 5000 and you get 1000; type 0 or a non-numeric string and the tool falls back to 10. The page generates a batch on load with the defaults, so it is never empty.
For a quick paste into a migration or a test fixture, 10 is usually enough. For a seed file for a staging database, we have found that requesting the exact row count you need is better than over-requesting, because a stray CSV row of UUIDs that no fixture references is just noise in review.
The value that trips people up is that every run produces fresh values. If your integration tests compare against a fixture file, download the batch with the .txt button and commit that file; do not regenerate the UUIDs on each test run and expect the fixtures to match.
The .txt download writes the same text you see in the list via a client-side Blob URL, and the copy buttons copy exactly what is displayed — including uppercase and hyphen settings in effect at that moment.
Common mistakes when UUID v7 is your primary key
The first mistake is assuming strict monotonicity. A UUID v7 is sortable by timestamp, but within the same millisecond the ordering comes from the 74 random bits, so two values generated microseconds apart can appear in either order when sorted as strings. RFC 9562 describes v7 as sortable, not as a strictly increasing sequence.
The second is generating primary keys in the application when the database can do it better. If your database supports a v7 function natively, letting it assign ids keeps the timestamp consistent with the transaction clock and avoids clock skew between application servers. Use this generator for fixtures and tests, not as a hidden dependency in production code paths.
The third is treating a UUID as a secret. A v7 value has only 74 random bits, and the timestamp is readable. RFC 9562's security considerations advise against relying on UUIDs as security capabilities; use a dedicated random token for password resets, invite links, and API keys.
Finally, storing the text form in a CHAR(36) column wastes space compared with a native 16-byte uuid type, and it changes how B-tree indexes behave. Convert on insert when you can.
Does a UUID v7 leak creation time?
Yes. Anyone holding a v7 can decode the first 48 bits and recover the creation time to the millisecond, plus the approximate order in which a set of records was created. That is a feature for sorting and a liability for public-facing identifiers.
If an order number, invoice reference, or public profile slug is a v7, an observer can estimate when the record was created and, by sampling, how fast you are creating records. For internal primary keys that never leave your database this rarely matters; for anything a customer can see, consider a v4 UUID or an opaque token instead.
The same instinct applies elsewhere in identifier design. Randomizing hardware addresses so they do not expose vendor or device information is the reasoning behind the Random MAC Generator on the same site, and it is worth applying the same question to every id you hand to a client: what does this reveal besides being unique?
A middle path many teams use: keep v7 as the internal primary key for index locality, and expose a separate random public id in APIs and URLs.
Sanity-check a batch before you paste it in
Three checks catch almost every formatting problem. The string should be 36 characters with hyphens or 32 without; the 13th hex character (the first character of the third group) should be 7; and the first character of the fourth group should be 8, 9, a, or b, because those are the only valid variant encodings.
As a concrete example, 0190a1b2-c3d4-7e5f-8a9b-0c1d2e3f4a5b passes all three: 36 characters, a 7 in the version position, and 8 in the variant position. If you see something else in those slots, you are not looking at a v7.
Also confirm the count matches what you asked for, since the count field clamps silently rather than rejecting out-of-range input. Sorting the list and comparing the first group of each line is a quick way to confirm the batch is time-ordered.
We built the generator to be a convenience, not an authority. If the ids are going into a production migration or a compliance record, verify them against your database's own UUID validation and the RFC, and keep a copy of the batch you actually used.
Frequently asked questions
Are the UUIDs from UUID v7 Generator real RFC 9562 values?
Yes. Every value has the correct 128-bit layout: a 48-bit millisecond timestamp, a version nibble of 7, and variant bits of 10, which is why the fourth group always starts with 8, 9, a, or b. You can check any line against RFC 9562 yourself; no reformatting is applied beyond the uppercase and hyphen toggles.
Is UUID v7 Generator free, and does it send anything to a server?
It is free and requires no account, and the generation runs entirely in your browser with client-side JavaScript. Nothing is uploaded, and the .txt download is assembled locally through a Blob URL. That also means the tool works offline once the page has loaded, and closing the tab discards the batch unless you copied or downloaded it.
UUID v4 vs v7 — which should I use as a primary key?
Use v7 when you want database index locality, because its leading timestamp keeps inserts clustered near the end of the B-tree. Use v4 when the identifier is public and you do not want to reveal when a record was created. Many systems use both: a v7 primary key internally and a separate random public identifier in URLs and APIs.
Can UUID v7 Generator produce duplicate values in one batch?
A duplicate would require two values generated in the same millisecond that also share all 74 random bits, which is a 1-in-2^74 chance for each pair within that millisecond. That is far below any practical risk for seed data or tests. For uniqueness guarantees, though, rely on your database's primary key constraint rather than on probability.
Why do generated UUIDs sometimes look out of order?
Because values created in the same millisecond share an identical timestamp prefix, and the remaining 74 bits are random. Sorting them as strings therefore orders them by chance within that millisecond, not by generation order. Neighbouring milliseconds always sort correctly, so v7 is sortable but not strictly monotonic.