UUID Generator

What is a UUID generator?

A UUID is a 128-bit identifier that can be minted anywhere, by anyone, without asking a central authority whether the number is already taken. No database round trip. No sequence to lock, no coordination between services, no negotiation between two machines that have never heard of each other. That is the whole trick, and it is why UUIDs turn up as primary keys, message IDs, trace IDs, S3 object names, and idempotency keys. This tool produces them in your browser, in the canonical 36-character form: eight hex digits, three groups of four, then twelve, separated by hyphens.

Two versions are offered. Version 4 is 122 bits of randomness with a version marker and a variant marker stamped over the rest, and it is what nearly every language runtime hands you by default. Version 7 puts a Unix millisecond timestamp in the leading 48 bits and fills the remainder with random and counter bits, so a run of them sorts in the order it was created. Choose a version, choose how many you want (one, or up to a hundred at a time), and press Regenerate for a fresh batch. Hyphens can be switched off and the hex can be shown uppercase. Both are display settings and neither changes the identifier underneath.

When to use it

Most visits here are about needing one identifier, now, by hand. You are writing a seed file and three rows need distinct primary keys. You are testing a payment endpoint with curl and the request wants an idempotency key. A fixture needs a tenant ID that will not clash with the one in the other fixture. A correlation ID has to go into a header so you can grep for it in the logs afterwards. Reaching for a Python REPL or a uuidgen shell alias works, but it is four keystrokes more than clicking a button, and it does not give you fifty of them at once for a load-test dataset.

If the identifier is going to be a primary key in Postgres, MySQL, or SQL Server, take the time to pick the right version, because it has real consequences for the table. Version 4 values are effectively random, so consecutive inserts land at random positions across the index. The B-tree ends up dirtying pages all over the file rather than one hot region, buffer cache hit rates drop as the table grows past memory, and pages split in the middle instead of appending at the right edge. Version 7 fixes exactly that. Because the first 48 bits are a timestamp, today's inserts cluster together at the far right of the index, which is where an auto-increment integer would have put them anyway. You keep the decentralised generation and you stop paying for it in random I/O.

There is a case for not using a UUID at all, and it is worth hearing before you make every table 16 bytes wider. An auto-increment bigint is 8 bytes, a UUID is 16, and that difference is multiplied by every index and every foreign key that references the row. Integers are also readable. A support agent can say "order 41822" down a phone line; nobody has ever read a UUID aloud. If your rows are created in one place, by one database, and you have no plans to merge shards or accept client-generated IDs, a sequence is smaller, faster, and easier to debug. UUIDs earn their cost when IDs originate outside the database: on mobile clients while offline, in a queue consumer, across shards, or in any system where you need the ID before the insert has happened.

How this tool works

Every byte comes from your browser's cryptographic random source. Version 4 uses crypto.randomUUID where the page has it available, and falls back to crypto.getRandomValues with the version nibble set to 4 and the variant bits set to 10 by hand. Math.random is never used for either version, anywhere in this tool. It is a fast non-cryptographic PRNG with a small internal state, and identifiers built on it have been guessed in the wild.

Version 7 is assembled byte by byte. The current time in milliseconds is written big-endian into the first six bytes, then the version nibble 7, then twelve bits that this tool uses as a counter, then the two variant bits, then 62 bits from the CSPRNG. The counter is the reason a batch of one hundred comes back already in order: a hundred UUIDs generated back to back all share the same millisecond, and if those twelve bits were random the batch would sort arbitrarily inside that millisecond. RFC 9562 anticipates this and describes the fixed-length counter as one of its monotonicity methods. The counter is re-seeded from the CSPRNG on every new millisecond, so it says nothing about how many you have generated, and if the clock steps backwards the previous timestamp is held rather than reused.

The hyphen and case switches are presentation only. Turning hyphens off gives you the 32-character form that MySQL BINARY(16) helpers and some SDKs expect, and uppercase matches the convention in .NET and older Microsoft tooling, but the value on the clipboard is the same 128 bits either way. Batch size is clamped to a whole number between 1 and 100 before anything is generated, so a pasted value or a stray keystroke cannot ask for a million. All of it runs in the tab you already have open. Nothing is uploaded, no server sees the values, and no two visitors can be handed the same batch, because there is no shared source to hand them from. One honest caveat: a version 7 UUID contains the moment it was created, in plaintext, readable by anyone who has it.

Examples

• One version 4 UUID, the default settings

  Input

  Version 4, batch of 1, hyphens on, lowercase

  Output

  4c4e0d0e-a00d-416c-a3e9-f2c64f840480

  Read the two fixed positions. The first character of the third group is 4, which is the version. The first character of the fourth group is a, which is one of 8, 9, a, or b and marks the RFC 9562 variant. The other 122 bits are random. Those two markers are how a parser tells a version 4 value apart from a version 1 or a version 7 one.

• A batch of three version 4 UUIDs

  Input

  Version 4, batch of 3, hyphens on, lowercase

  Output

  4c4e0d0e-a00d-416c-a3e9-f2c64f840480
  19a849f9-0ebf-4322-9969-b926f25a0ec6
  bf11effe-515e-421f-90cc-37deec555283

  One sample rather than a fixed result: press Regenerate and you get three different values. Note what these three have in common, which is nothing beyond the version and variant markers. They were created milliseconds apart and they sort into an order unrelated to that. This is the property that scatters index inserts.

• A batch of four version 7 UUIDs

  Input

  Version 7, batch of 4, hyphens on, lowercase

  Output

  01a03c50-e675-749e-b2de-4ec4ab23a7f1
  01a03c50-e675-749f-b05d-1c58f3d8ab25
  01a03c50-e675-74a0-a5a9-6da703a35b4d
  01a03c50-e675-74a1-99f6-f6a03a41fecf

  Also one sample. All four share the prefix 01a03c50e675, which is the 48-bit timestamp 1787718329973, or 2026-08-26T04:25:29.973Z: the whole batch was created inside a single millisecond. Then look at the counter running 49e, 49f, 4a0, 4a1 immediately after the version 7 nibble. That is what keeps them sorted when the timestamp cannot separate them. The last 62 bits stay random, which is what keeps them distinct and unguessable.

• The same value with both format switches flipped

  Input

  3b488465-e721-424c-80a8-63055d9517d7

  Output

  3B488465E721424C80A863055D9517D7

  Hyphens off, uppercase on. Thirty-six characters becomes thirty-two, which is the form you want when the column is a fixed-width string or when you are about to hand it to a binary conversion helper. The 128 bits are untouched. Parse either string and you get the same identifier back.

Frequently asked questions

• Should I use UUID v4 or v7?

  Use version 7 if the value is going to be a primary key or anything else that gets indexed heavily, and version 4 if it is a standalone token, a filename, a trace ID, or anything where creation time should not be visible. The index argument is the one that moved the industry: random v4 keys spread inserts across the whole B-tree, so as the table outgrows memory the database starts reading and writing pages from disk almost at random, page splits happen mid-node instead of at the edge, and write amplification climbs. A v7 key sorts by time, so new rows land next to each other in a small hot region of the index, exactly as an auto-increment key does. The cost is that anyone holding the ID can read the second it was created.

• Is UUID version 7 an official standard?

  Yes. RFC 9562 was published in May 2024 and obsoletes RFC 4122, the 2005 document that defined versions 1 through 5. RFC 9562 keeps all of those and adds versions 6, 7, and 8. Version 7 is the time-ordered one intended for new work. Library support arrived before the RFC did, during the long draft period, so some older implementations differ in details around monotonicity, though the field layout has been stable throughout. Postgres shipped a native uuidv7() function in version 18. Before that, and for other databases, a short PL/pgSQL function or a client-side library covers it.

• Can two UUIDs ever be the same?

  In principle yes, and in practice the arithmetic makes it a non-issue. A version 4 UUID carries 122 random bits. By the birthday bound you would need to generate roughly 2.3 quintillion of them before there is a 50 percent chance of a single collision, and around 100 trillion before the chance reaches one in a billion. At a million a second that first number takes about 73,000 years. The real risk was never the size of the space. It is a broken random source: a seeded PRNG, an embedded device generating IDs before its entropy pool has filled, or a library that falls back to Math.random without saying so. Collisions in the wild have come from that, not from the odds.

• What is the difference between a UUID and a GUID?

  Nothing, at the level of the 128 bits. GUID is Microsoft's name for the same thing, and the two terms are interchangeable in conversation. The differences are conventions. Microsoft tooling usually prints them uppercase and often wraps them in braces, so you see {3B488465-E721-424C-80A8-63055D9517D7} in registry keys and COM interfaces. There is a sharper trap in .NET: the Guid struct stores the first three fields in native little-endian order, so calling ToByteArray gives you a byte sequence whose first eight bytes are reversed relative to the string you just read. Round-tripping through the string form avoids it. Round-tripping through raw bytes between .NET and almost anything else does not.

• How should I store a UUID in a database?

  As 16 bytes, not as a 36-character string. Postgres has a native uuid type that is exactly 16 bytes wide. MySQL has no UUID column type, so use BINARY(16) with UUID_TO_BIN and BIN_TO_UUID rather than CHAR(36). SQL Server has uniqueidentifier. Stored as text you are paying 36 bytes per value instead of 16, and often more once the column is a varchar with its own length overhead, and you pay it again in every index and every foreign key. On a table of 50 million rows with three indexes on the ID, that difference runs to gigabytes of extra pages, most of which have to fit in memory to be useful. Storing UUIDs as strings is the single most common reason people conclude that UUID keys are slow.

• Is a UUID safe to use as a session token or a password reset link?

  A version 4 UUID from a cryptographic random source carries 122 bits of entropy, which is more than enough to resist guessing, so it is defensible for a one-time reset link. Two conditions attach. The generator has to be a real CSPRNG, which is what crypto.getRandomValues and crypto.randomUUID guarantee and what a hand-rolled Math.random implementation does not. And the value has to be treated like a secret afterwards: expired, single-use, and kept out of logs, referrer headers, and analytics. Version 7 is a different matter and should never be used this way. It exposes its creation time and, in this tool, leaves 62 random bits rather than 122. For anything on the security-critical path, a purpose-built 256-bit random token is the clearer choice.

• Our IDs are hurting write performance. Can you help?

  Yes, and the request usually arrives disguised as something else. Teams rarely need a UUID button. They need a migration that converts an existing bigint primary key to v7 without downtime, a shim that keeps a legacy v4 column working while new rows get time-ordered IDs, or a decision on whether their write-heavy table is slow because of the key type or because of something else entirely. Zinc Online Solutions takes on the whole piece: the schema change, the backfill, and the measurement that says whether it helped. Describe the table and how the IDs are generated today, and we will tell you where the cost is coming from.