UUID generator

What this tool does

Pick a version, say how many you want and press Generate. Version 4 — the random one almost everybody means when they say UUID — is the default, and a quantity of one is what you usually want; raise it when you are seeding a database, filling a fixture file or preparing test data, and copy the whole batch in one go.

Versions 3 and 5 work differently, so the form changes when you choose them: instead of a quantity they take a namespace and a name, because the identifier is derived from those two things rather than invented. Asking for a hundred of them would give you the same value a hundred times, which is the entire point of them.

The NIL UUID is the all-zero value, listed here because it is a real, specified identifier used to mean "no UUID", and because typing thirty-two zeroes by hand is a good way to get it wrong.

Every batch appears above the previous one, so you can generate a few sets without losing the earlier ones while you paste them. Nothing is stored: a refresh clears everything.

What a UUID actually is

A UUID is 128 bits, written as 32 hexadecimal digits in five groups separated by hyphens: 8-4-4-4-12. Those hyphens are pure convention — the value is the 128 bits, and the same identifier may legitimately appear with braces around it, as a urn:uuid: string, or as 32 characters with no hyphens at all. Case is not significant either; the specification says to generate lower case and to accept both.

Two small pieces of the value are not free. The first digit of the third group is the version, which is why every version 4 UUID has a 4 there and every version 1 has a 1. The first digit of the fourth group encodes the variant, and for the modern format it is always 8, 9, a or b. Together they take four and two bits respectively, which is why a version 4 UUID carries 122 random bits rather than 128.

Being able to read those two positions is genuinely useful: given an identifier from a log or a database, you can tell at a glance whether it was random, time-based or derived from a name — and therefore whether two systems producing "the same kind of id" are actually doing the same thing.

The versions, and which to use

Version 4 — random. The right default for nearly everything. 122 bits from the operating system random generator, no structure, no information about when or where it was made. Use it for primary keys, request identifiers, file names, idempotency keys and anything else that just needs to be unique.

Version 1 — time-based. Built from a timestamp in 100-nanosecond intervals since 1582, a clock sequence and a node identifier. Its appeal is that identifiers made close together sort close together, which is kind to database indexes. Its historical problem is that the node identifier was originally the machine's MAC address, which leaked hardware identity into every record — this page uses a random node with the multicast bit set instead, exactly as the specification permits, so nothing about your machine is embedded.

Versions 3 and 5 — derived from a name. These are not random at all: they hash a namespace UUID together with a name, so the same pair always produces the same identifier, on any machine, forever. Version 3 uses MD5, version 5 uses SHA-1; prefer version 5 unless something requires the other. They are the answer to "I need a stable id for this URL, this hostname, this file path" without keeping a lookup table anywhere.

NIL. All zeroes, meaning explicitly "no identifier". Useful as a sentinel, though be careful: some systems treat it as a valid key and some reject it, and a NIL that arrived by accident looks identical to one that was meant.

Two newer versions are worth knowing about even though they are not offered here: version 7 embeds a Unix timestamp in a way that sorts correctly and is now the recommended choice for database keys, and version 6 is a reordered version 1 with the same aim. Support is still uneven, and version 4 remains the safe answer where it is not available.

How unique is version 4, really?

122 random bits is about 5.3 × 10³⁶ possible values. The number people actually want is the probability of a collision, which follows the birthday problem rather than intuition: you would need to generate roughly 2.7 × 10¹⁸ identifiers before the chance of any two matching reaches one in a billion. At a million UUIDs a second, that is longer than the universe has existed.

Which means the honest answer is: for any real system, no, you will not see a collision — provided the randomness is real. That last clause is where things actually go wrong. Collisions in the wild have come from generators seeded with the current time, from virtual machines cloned with identical entropy pools, and from language libraries that quietly fall back to a weak random source. This page uses crypto.getRandomValues, which is the browser interface to the operating system cryptographic random source.

One thing a UUID is not, despite the bits: a secret. Version 4 is unguessable in practice, so it is reasonable as an unguessable URL component, but version 1 is highly predictable if you know roughly when it was made, and versions 3 and 5 are fully reproducible by anyone who can guess the name. Never treat "it has a UUID in the URL" as an access control.

Namespaces, and what versions 3 and 5 are for

The namespace is itself a UUID, and it exists so that the same name in different contexts produces different identifiers. The specification defines four standard ones — DNS, URL, OID and X.500 — and you can equally use one of your own: generate a version 4 UUID once, write it down, and it becomes the namespace for your application forever.

The use case is deterministic identity. If every system in your estate needs the same identifier for the same customer reference, the same document path or the same hostname, deriving it with version 5 means no coordination and no shared table: each system computes it independently and gets the same answer. It also means an identifier can be recomputed after a data loss rather than being gone.

The trade-off is that the identifier reveals that a given name exists, to anyone who can guess the name and knows the namespace. Deriving a UUID from an email address does not hide the email address — anyone can hash a list of candidates and compare. If the name is sensitive, version 4 with a stored mapping is the safer design.

Storing them without regret

A UUID is 16 bytes. Stored as a 36-character string it is more than twice that, and every index, join and foreign key pays the difference. In PostgreSQL use the native uuid type; in MySQL use BINARY(16), and be aware that MySQL UUID_TO_BIN(x, 1) will also swap the time fields of a version 1 UUID so that it sorts chronologically.

That sorting question is the other thing worth planning for. Random identifiers arrive in no order, so each insert lands in a random place in the index — on a large table with a clustered primary key, that is measurably slower than sequential keys and fragments the index as it grows. If a table is going to be very large, that is the argument for a time-ordered identifier such as version 7, or for keeping an internal auto-increment key and exposing the UUID publicly.

Two smaller habits worth having: normalise case on the way in, since the same identifier can arrive in either, and accept the hyphen-less and braced forms rather than rejecting them — every one of those is the same 128 bits, and a validator that insists on one spelling will eventually reject a value that is perfectly valid.

A worked example

Leave the version on 4 and the quantity on 1, and press Generate: you get something like 3f2b1c4e-…-4a9d-…, where the 4 at the start of the third group is the version and the first digit of the fourth group is 8, 9, a or b. Raise the quantity to 10 and you get a numbered batch you can copy in one action.

Now switch to version 5, leave the namespace on DNS and type example.com as the name. The result is cfbff0d1-9375-5685-968c-48ce8b15ae17 — and it will be that value on every machine, in every language, every time, because it is derived rather than generated. Change the namespace to URL with the same name and you get a completely different identifier, which is exactly what namespaces are for. Switch to version 1 and generate ten: notice how much of the string the ten share, because the timestamp is the leading part.