A UUID is a 128-bit value designed so that independent systems can mint identifiers without coordinating. Two servers can generate them simultaneously without colliding, which means you never have to wait for a database to assign an ID and records created offline sync cleanly later.
This tool generates v4, which is essentially all random, and v7, which sorts chronologically. v7 is relatively new — standardised in RFC 9562 in 2024 — and puts the creation time in the leading 48 bits so that lexical order matches creation order. That single property makes it substantially better than v4 as a database primary key.
How to use
- Pick a version — Use v4 for general purposes and v7 if these will become database primary keys.
nilis the all-zero UUID used to mean "no value";maxis the all-f value that sorts last. - Set count and format — Generate up to 1000 at once. Output as the canonical hyphenated form, 32 characters without hyphens, a
urn:uuid:prefix or wrapped in braces, in either case. The hyphenless form suits URL paths; the braced form is what Microsoft tooling expects. - Copy or download — Copy the whole batch, copy individual lines, or download as
.txt. Generating a batch up front is handy when you need values for test fixtures or a database seed script. - Inspect an existing UUID — Paste any UUID into the inspect box to read its version and variant. For v1, v6 and v7 it also extracts the embedded creation time, so an ID in a log tells you when the record was made.
Frequently asked questions
Are UUIDs really guaranteed unique?
v4 carries 122 random bits. Generating a billion per second for a century still leaves you below a 50% chance of a single collision, so in practice you can treat them as unique.
That maths assumes a sound source of randomness. This tool uses crypto.getRandomValues, which is cryptographically secure, but some languages' default generators — Math.random, C's rand — are predictable and must never be used to build UUIDs. Check what your library uses.
Should I use v4 or v7?
For database primary keys, v7. Most databases index primary keys with a B-tree, and v4's randomness scatters inserts across the whole index. Every insert risks a page split, evicts cache and inflates the index — write throughput suffers noticeably at scale.
v7 increases over time, so new rows append at the end of the index, giving you an insert pattern close to an auto-increment integer while keeping the distributed generation that makes UUIDs worth using. For public identifiers exposed in URLs, v4 may still be preferable because it reveals no creation time.
Does v7 leak information by embedding a timestamp?
Yes. Anyone holding a v7 UUID can read the creation time down to the millisecond.
Usually that is harmless — signup dates and order times are typically displayed anyway. But where the timing itself is sensitive, such as when a confidential document was drafted or when a trade was placed, expose v4 externally and keep v7 as the internal primary key.
Do UUIDs stay ordered within the same millisecond?
In this tool, yes. A v7 timestamp has millisecond resolution, so several generated in the same millisecond share the leading 48 bits and would otherwise shuffle randomly.
RFC 9562 anticipates this, and this tool implements its "method 1": the 12 bits immediately after the timestamp act as a counter that increments within a millisecond. Generate a thousand at once and they still sort in creation order.
Concepts worth knowing
How the 128 bits are laid out
In the 36-character form xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, the M position holds the version and the high bits of N hold the variant. Everything else is payload that differs by version.
The variant tells you which specification the UUID follows. Anything generated today is almost certainly the RFC 9562 variant, where N is 8, 9, a or b. This tool's inspector reads exactly those two positions, which is often enough to guess where an unfamiliar UUID came from.
Store them as 16 bytes
Storing UUIDs in a VARCHAR(36) column is the most common mistake. The real value is 16 bytes; the string form costs 36, more than doubling storage and bloating the index enough to hurt cache efficiency.
PostgreSQL has a native UUID type. MySQL should use BINARY(16) with UUID_TO_BIN() and BIN_TO_UUID(). Note that MySQL 8.0's UUID_TO_BIN(uuid, 1) rearranges v1's time fields to make them sortable — with v7 you are already sorted, so store it without the second argument.
When you need something shorter
UUIDs are long for URLs. Thirty-six characters clutter an address and nobody is going to type one out.
You can encode the same 128 bits as Base64 or Base32 to get roughly 22 characters, or reach for NanoID or ULID, which were designed short from the start. ULID keeps v7-style chronological sorting in a 26-character Base32 form. That said, UUIDs are natively supported by essentially every language and database, so unless brevity is a real requirement, staying with UUID is the low-friction choice.