GUID & UUID Generator

Generate UUIDs — v4, v7, v1, v5 or nil — one at a time or a thousand at once

Choose a version, set a quantity between 1 and 1000, pick an output format and generate. Copy a single value, copy the whole batch, or download it as a text file, a CSV or a JSON array. There is also a parser at the bottom of the page: paste any UUID and it reports the version, the variant, the five structural fields, and — for the time-based versions — the embedded timestamp decoded to an ISO date.

Everything is generated in your browser. Random bits come from the Web Crypto API’s cryptographically secure generator, not Math.random. No values are sent anywhere, none are stored, and no two visitors can be handed the same batch by a server that got its bookkeeping wrong — because there is no server involved.

The five options, and when each is the right answer

v4 — random, and the one to use unless you have a reason not to

A v4 UUID is 128 bits of which 122 are random; the other six are fixed by the specification to mark the version and the variant. It encodes nothing. It reveals nothing about when it was made, on what machine, or in what order relative to its siblings. Two independent processes on opposite sides of the world can mint v4 identifiers with no coordination whatsoever and expect never to collide, which is the entire point of the format.

That opacity is a feature when the identifier will be visible — in a URL, an API response, a webhook payload — because a v4 value leaks no information and cannot be enumerated by incrementing. It is a liability inside a database index, for reasons below.

v7 — time-ordered, and what you want for a primary key

A v7 UUID puts a 48-bit Unix timestamp in milliseconds into the leading bits, then fills the rest with cryptographically secure random data. The consequence is the useful part: sorting v7 values as strings or as bytes sorts them by creation time, because the most significant bits are the clock.

That single property is what makes v7 the sensible default for database primary keys. B-tree indexes on most engines store keys in sorted order. Inserting sequential keys appends to the same region of the index, so the pages being written stay in memory and the tree grows tidily at one end. Inserting random keys — which is exactly what v4 gives you — scatters writes across the whole index. Every insert lands on a different page, that page has to be read in if it is not cached, and pages that fill up split. On a large table with a random primary key you get more buffer-pool churn, more page splits, more fragmentation and a physically larger index than the same data keyed in time order. This is the well-documented reason teams historically preferred auto-increment integers over UUID primary keys; v7 is the format that removes the reason.

The costs are real but small. A v7 value discloses its own creation time to anyone holding it, so do not use it where that is sensitive — it is a poor choice for a password-reset token or an unguessable share link, even though the random portion is generated securely. And two v7 values minted in the same millisecond have no defined order between them; v7 gives you coarse chronological ordering, not a strict monotonic sequence. If you need to know which of two events in the same millisecond came first, you need a real sequence number, not a UUID.

v1 — timestamp and node, mostly of historical interest

A v1 UUID also embeds a timestamp, but with two awkward differences from v7. The clock is a count of 100-nanosecond intervals since 15 October 1582 — the start of the Gregorian calendar — and the timestamp is split across three fields in a scrambled order, with the low-order bits first. That layout means v1 values do not sort chronologically as strings, which is why v1 never delivered the index benefit that v7 does.

The other difference is the node field, the last twelve hex digits. It was originally specified to hold the generating machine’s MAC address, which is why v1 has a privacy reputation: a v1 UUID could identify the physical host that produced it and reveal roughly when. Modern implementations, including the one behind this page, generate that node value randomly instead rather than reading a real network interface — a browser cannot see your MAC address in any case. Treat v1 as something to generate when you are matching an existing system’s format, and reach for v7 for anything new.

v5 — the same input always yields the same UUID

v5 is not random at all. It hashes a namespace UUID together with a name string using SHA-1 and formats the result as a UUID. Feed it the same namespace and the same name and you get the same value every time, on any machine, forever. That makes it the tool for deriving a stable identifier from something you already have — a domain name, a file path, an external system’s key — without storing a mapping table.

The four namespace UUIDs defined by the specification are offered directly, and you can supply your own:

• 6ba7b810-9dad-11d1-80b4-00c04fd430c8 — DNS, for hostnames
• 6ba7b811-9dad-11d1-80b4-00c04fd430c8 — URL
• 6ba7b812-9dad-11d1-80b4-00c04fd430c8 — ISO OID
• 6ba7b814-9dad-11d1-80b4-00c04fd430c8 — X.500 distinguished name
• Custom — any valid UUID of your own, which is how you keep your derived identifiers from colliding with anyone else’s

Two consequences follow from determinism. Generating a batch of v5 UUIDs with the same name gives you the same value repeated, which is correct behaviour rather than a bug. And because v5 is a hash of the input, anyone who can guess the name and knows the namespace can compute the UUID — so a v5 identifier derived from an email address is not a secret. Note also that this generator produces v5; it does not offer v3, the older MD5-based equivalent.

The nil UUID

00000000-0000-0000-0000-000000000000 is a specific value defined by the standard: 128 zero bits, all fields zero. It is the canonical way to express "no UUID here" in a field that must contain a syntactically valid UUID and cannot be null — a non-nullable database column during a migration, a protocol field with a fixed width, a default in a struct.

Its trap is that it looks valid to every validator, so a nil UUID that arrives because of an uninitialised variable rather than a deliberate choice will pass every check and fail every lookup. Treating nil as a real error condition in your code is usually correct. It is worth knowing that the standard also defines a max UUID of all f digits; this tool does not generate that one.

Collision probability, stated honestly

A v4 UUID has 122 random bits, so the space of possible values is 2 to the power of 122. That is a number with thirty-seven digits, and the practical consequence is that for any workload a normal application will ever produce, an accidental duplicate is not something to design around. Software engineering folklore is full of specific-sounding odds for this; most of them are repeated without a source, so here is the claim without a fabricated statistic: the space is large enough that collisions from correctly generated v4 UUIDs are not a realistic operational concern, and a unique constraint on the column is the appropriate and cheap belt-and-braces measure.

The failure that does happen in the real world is not the birthday problem — it is a broken random source. UUIDs generated from a poorly seeded pseudo-random generator, or from the same seed on many freshly booted identical VMs or containers, can and do repeat. That is a bug in the generator, not a property of the format. This page uses the browser’s cryptographic random source, which is the right one.

v7 collision behaviour differs slightly and favourably: because the leading bits are a timestamp, two v7 values can only collide if they were generated in the same millisecond and their random portions matched, which is a smaller space of opportunity than v4’s.

Output formats

The same 128 bits get written down in several conventional ways, and different ecosystems expect different ones. Choose the one your target wants:

These are presentation choices only — the underlying value is identical in all five. Case is not significant when comparing UUIDs, and the canonical output form is lowercase, but a string comparison in your code is case-sensitive, so a system storing uppercase and a system storing lowercase will fail to match records that are in fact the same. Normalise on the way in. Similarly, if you strip hyphens for storage, strip them consistently; a mixed table is a long afternoon.

Batches and exports

The quantity field takes any number from 1 to 1000, with one-click shortcuts for 10, 100 and 1000 — enough to seed a test fixture, populate a staging table or pre-allocate a block of identifiers. The whole batch can be copied to the clipboard in one action, or downloaded three ways: plain text with one UUID per line, CSV with columns for the UUID, the version and a generation timestamp, or JSON with the version, format, count, timestamp and the array of values. All three apply the format you selected.

The parser: reading a UUID someone handed you

Paste a UUID into the parser and it reports what the value actually is, which is faster than counting hex digits by eye. It gives you the version number read from the version nibble, the variant, and the five canonical fields — time-low, time-mid, time-high-and-version, clock-sequence and node — broken out separately. For v1 and v7 it also decodes the embedded timestamp to an ISO 8601 date and to milliseconds since the Unix epoch, each version using its own clock convention.

That timestamp readout answers real questions. When was this record actually created, when the created_at column is missing or looks wrong? Is this identifier from the migration or from after it? Is the batch someone sent me actually from the window they claim? It also demonstrates the privacy point about v7 and v1 in the most direct way possible: the creation time is not metadata alongside the identifier, it is inside it, readable by anyone.