UUID Generator (v4 and v7)

Generate UUIDs in bulk, random v4, or time-sortable v7 for database keys. Generate one or a thousand, shaped for wherever they are going: one per line, a JSON array or a quoted comma list, in uppercase, brace-wrapped or hyphen-free form if that is what your system expects. An inspector reads any pasted UUID back: its version, its variant, and for v1 and v7 the creation time hiding inside it.

What the parts mean

A UUID looks like 0192f8c1-4d3e-7a2b-9c1d-5e6f7a8b9c0d. The digit beginning the third group is the version (4 or 7 here) and the first digit of the fourth group encodes the variant, which is why it is almost always 8, 9, a or b. Those bits are fixed by the specification, which is why a UUID has 122 random bits rather than 128.

Why v7 exists

Random UUIDs have a well-documented cost as database primary keys. Databases store indexes as balanced trees ordered by key. Insert sequential keys and each new row goes at the end, touching one page. Insert random keys and every row lands somewhere different, so the database keeps loading and splitting pages all over the index. On a large table the write slowdown and the disk churn are substantial.

v7 fixes this without giving up independent generation. Because the leading 48 bits are the current time in milliseconds, identifiers made close together sort close together, so inserts cluster the way sequential integers do. You keep the ability to generate keys anywhere, and lose the index fragmentation.

One detail matters if you generate them in bulk. A loop produces thousands of identifiers inside a single millisecond, and if the bits after the timestamp were purely random they would sort arbitrarily, losing exactly the property you chose v7 for. This generator uses the monotonic counter the specification allows, so a batch of a thousand comes out in order rather than merely grouped by millisecond.

It was standardised in RFC 9562 in 2024, replacing a decade of homegrown variants that solved the same problem incompatibly.

Reading a UUID back

A UUID also answers questions, if you know where to look, and the inspector under the generator looks for you. Paste any UUID and it reports the version (which recipe made it), the variant (which standard's bit layout it follows), and for v1 and v7, the timestamp embedded in it decoded to a readable date. That last one is regularly useful in debugging: a v7 primary key quietly records when its row was created, so a mysterious record's identifier can tell you it appeared at 3am during the failed deploy. It works the other way too: before choosing v7 for anything public, paste one and see exactly how much it tells a stranger.

Where UUIDs are worth it

They are the natural choice when identifiers must be created without coordination, offline mobile clients, several services writing to the same table, or data merged from systems that each had their own counter. They also avoid leaking business information: a sequential integer in a URL tells anyone who looks roughly how many records you have and lets them guess neighbouring ones.

The trade-off is size and readability. A UUID takes 16 bytes stored properly, or 36 characters as text, against 4 or 8 for an integer, and nobody reads one aloud. For a small single-database application, an auto-incrementing integer is usually the better engineering choice.