Generate 5 UUIDs at Once - Version 4, Ready to Copy

Every one of these is 128 bits. The only question is where the bits come from

Six versions, five output formats, up to 100 at a time, and a second mode that takes an identifier somebody else made and tells you what is inside it. Pick a version, press the button, and you get the identifiers plus a color coded map of the first one showing which characters carry the version, which carry the variant and which are simply random. Ask for version 5 with the DNS namespace and the name liczgrupa.pl and the answer is always a62d1cd5-f3af-53ff-892f-2ff099b09f12, on this machine and on yours, today and next year.

128

bits, in every version

122

of them random in version 4

6

bits that are never random

That last tile is the part most explanations skip. A version 4 identifier is not 128 random bits. Four bits at character 15 spell out the version and two bits at character 20 spell out the variant, which is why the fifteenth character of a version 4 value is always 4 and the twentieth is always one of 8, 9, a or b. Anything claiming to be a UUID that fails those two checks is a string shaped like one.

The atlas: which version, and what it admits about itself

The versions are not ranked. They answer different questions, and the interesting column is the last one, because an identifier that ends up in a URL, an email or a log file carries whatever it encodes to everyone who sees it.

Version	Where the bits come from	Sorts by time	What it reveals to whoever holds it
Version 4	122 random bits	No	Nothing
Version 7	48 bits of Unix milliseconds, then a counter, then 74 random bits	Yes	The moment it was created, to the millisecond
Version 1	60 bits counting hundred nanosecond intervals, a clock sequence, and a node field	No	The moment, and on many implementations the network card that made it
Version 5	SHA-1 of a namespace and a name, cut to 128 bits	No	Nothing directly, but a guessable name gives a guessable identifier
Nil	All 128 bits zero, a defined constant	Not applicable	Means absent, unknown or not applicable
Max	All 128 bits one, a defined constant	Not applicable	Useful as the upper bound of a range query

Versions 2, 3, 6 and 8 exist and the inspection mode names them, but none is produced here. Version 2 was defined for a security system almost nobody deployed, version 3 is version 5 with the weaker MD5 in place of SHA-1, version 6 is version 1 with the timestamp fields put back in order, and version 8 is a blank check for anyone who wants to define their own layout. If you have a free choice, the real decision is between 4 and 7, and it turns on whether the identifier is also going to be a database key.

Where the version and the variant actually sit

Thirty six characters, thirty two of them hexadecimal and four of them hyphens. The hyphens carry no information at all, which is why the unhyphenated form is the same value written more compactly. Two of the thirty two positions are structural and the rest belong to whichever version produced them. The inspection mode reads exactly these positions, so you can paste any identifier you have been handed and find out what made it.

Position	What lives there	Reading it
Characters 1 to 8	Time low, or random	In version 7 the first twelve characters are the timestamp, which is why they sort
Characters 10 to 13	Time mid, or random	Together with the block above, the millisecond in version 7
Character 15	The version nibble	Always the version number, so a version 4 value always has a 4 here
Characters 16 to 18	Time high, a counter, or random	In version 7 this is the counter that separates a batch made in one millisecond
Character 20	The variant	8, 9, a or b for the standard variant. Anything else is not one
Characters 21 to 23	Clock sequence, or random	Shared across a version 1 batch, which is how you spot one
Characters 25 to 36	The node field, or random	In version 1 this is a hardware address unless the low bit of the first byte is set

The consequence nobody mentions: a generator that fills all 128 bits at random and writes no markers produces a value failing the variant check roughly a quarter of the time, because only two of the eight possible patterns at character 20 are the standard variant. Paste one into the inspection mode and it says so rather than quietly accepting it.

A second one: the nil identifier has a version nibble of 0 and the max identifier has f, and neither of those is a version. They are defined constants, not malformed values, which is why the inspection mode names them instead of rejecting them.

Version 5 is the odd one out: the same name always returns the same identifier

Every other version draws. Version 5 computes. It takes a namespace, which is itself a UUID, and a name, hashes the two together with SHA-1 and cuts the result to 128 bits. Run it twice with the same pair and you get the same answer, on any machine, in any language, in any year. That makes it the only version you can use to turn something you already have, such as a domain or an invoice number, into a stable identifier without storing a lookup table anywhere. All six values below are produced by this tool and can be reproduced by pasting the same inputs.

Example 1, the published test vector: namespace DNS, name www.example.com
Result: 2ed6657d-e927-568b-95e1-2665a8aea6a2
This is the value the specification itself publishes for that pair, which is how you can tell the SHA-1 in here is the real thing and not an approximation.

Example 2, a domain of your own: namespace DNS, name liczgrupa.pl
Result: a62d1cd5-f3af-53ff-892f-2ff099b09f12

Example 3, an address: namespace URL, name https://liczgrupa.pl/en/generators/codes/uuid-generator
Result: 2bd5b37f-fa24-5abd-a8ad-1ba1e16bda95
Useful when a cache key or a deduplication key has to be derived from a page rather than assigned to it.

Example 4, the same input twice: namespace DNS, name invoice-11871, run once and then run again
Result both times: 14dfa223-5bb2-5173-8cd4-dabba147cad8

Example 5, one digit different: namespace DNS, name invoice-11872
Result: d85394a4-c47b-5746-a89c-28c75b6fca9a
Not adjacent to the previous one in any way. A hash spreads neighboring inputs across the whole range, which is exactly why you cannot sort these or guess the next one.

Example 6, the same name in a different namespace: namespace URL, name invoice-11871
Result: fa79250c-810e-53d2-8467-0990b4343324
The namespace is half the input. Two systems can hash the same string and never collide, provided they picked different namespaces and wrote the choice down.

Because it computes rather than draws, asking for ten of them makes no sense, and the tool says so instead of repeating one value ten times. If you need a stable identifier for something that has no natural name, version 5 is the wrong tool and version 4 is the right one.

Working the form, in order

Mode - generating new identifiers, or taking apart one you were given. The fields below change meaning between the two, and only the inspection field matters in the second.
Version - version 4 unless you have a reason. Version 7 if the identifier is also a primary key, version 5 if you have a name to derive it from, nil or max if you need the defined constants.
How many - anything from 1 to 100. Values outside that range are pulled back to the nearest end rather than refused, so a stray zero does not cost you the run.
Format - lower case is the standard output. The braced and URN forms exist because two ecosystems wrote them into their tooling decades ago and never stopped.
Namespace - version 5 only. Four are defined for you, and a fifth option takes a UUID of your own, which is the right choice for anything private to your system.
Custom namespace - the UUID to use when the option above is set to custom. It has to be a well formed identifier itself, and it is checked before anything is hashed.
Name to hash - version 5 only, and required there. Anything you like: a domain, an address, an order reference. Case, spacing and punctuation all count, so pin down a normal form before you write any of these into a table.
Identifier to inspect - inspection mode only. Hyphenated, unhyphenated, wrapped in braces or prefixed with the URN scheme, all four are accepted.
Read the result - the identifiers themselves, then the map of the first one, then the reference panel for the version you chose, then any notes worth acting on.

Five ways to write the same 128 bits

None of these formats changes the value. They change the number of characters, and therefore the column width, the comparison behavior and whether a value copied out of one system is recognized by the next.

Format	Characters	Where you meet it
Lower case, hyphenated	36	The standard output form. Use it unless something forces you not to
Upper case, hyphenated	36	Older Microsoft tooling. Accepted on input everywhere, produced by few things
Braced	38	Registry keys and configuration files that expect the braces to be part of the value
URN	45	Anywhere an identifier has to be a full URI, which includes a good deal of XML
No hyphens	32	Compact storage and some older APIs. The commonest source of a column holding both forms

That last row is worth a moment. A column typed as text accepts every one of these five, so one table can end up holding the same identifier written three ways, and no equality test will match them. A column typed as a native identifier type normalizes on the way in and the problem disappears. If you inherit a table where it did not, the inspection mode here reads all four input shapes and gives back the canonical one, which is the form to normalize to.

What the collision arithmetic says, and where identifiers quietly go wrong

Version 4 has 122 random bits, so there are about 5.32 x 10^36 distinct values. That number is too large to be useful on its own. The one that matters is the birthday figure: an even chance of a single collision arrives after roughly 2.7 x 10^18 identifiers. Generating a million a second, you would reach it in something over eighty thousand years. For a database key, that is settled.

Version 7 spends 48 of its bits on the timestamp and keeps 74 random, but those 74 only have to be unique inside a single millisecond, which gives an even chance of collision at about 1.6 x 10^11 identifiers in that same millisecond. Also settled. The timestamp runs out in the year 10889, which is not the constraint anyone should be planning around.

Where it does go wrong, one: using an identifier as a secret. The random bits here, and in most ordinary generators, come from the general purpose pseudorandom source, not a cryptographic one. That is fine for a key, a request identifier or a filename, where the requirement is not colliding. It is not fine for a session token, a password reset link or an invitation code, where the requirement is being unguessable. The notes say so on every version that draws, and the right tool for that job is a password generator with a cryptographic source behind it.

Two: version 1 and the node field. The specification lets an implementation use the real network card address there, and plenty do. An identifier like that hands over the machine that made it and the moment it was made, to anyone who ends up holding it. This tool fills the node with random bits and sets the multicast flag, which is what the specification asks for when there is no address to use, and the inspection mode warns you when a value you paste in has the flag clear.

Three: version 4 as a primary key on a large table. The values are random, so successive inserts land in random places in the index, which fragments it and pushes writes across pages that are no longer in memory. This is the entire reason version 7 was defined. If the identifier is a key and the table is going to be big, version 7 buys you back the insert locality without giving up the property that made you choose a UUID in the first place.

Four: storing the nil identifier as if it were real. All zeroes is a defined value meaning absent or unknown, and a row carrying it is a row with no identifier. It is a legitimate value to send; it is rarely a legitimate value to save.

Questions that come up once the identifiers are already in the table

Is a UUID the same thing as a GUID?

Yes. GUID is the name Microsoft gave the same 128 bit structure, and the two are interchangeable. The only practical difference you will meet is presentation: Microsoft tooling tends to write them in upper case and sometimes wrapped in braces, and both of those forms are available here.

Version 4 or version 7, if I only get one answer?

Version 7 when the identifier is going to be a primary key on a table that grows, because it sorts by creation time and keeps inserts together in the index. Version 4 when the identifier will be visible to someone who should not learn when the record was made, since version 7 carries the millisecond in plain sight.

Can two of these ever come out the same?

In principle yes, in practice no. Version 4 reaches an even chance of one collision at around 2.7 x 10^18 values. Far more realistic failure modes are a generator that is not actually random, a batch copied twice, or a test fixture reused in production, and none of those is a mathematics problem.

Are these safe to use as a password reset token?

No, and the tool says so in the notes. The bits come from the ordinary pseudorandom source, which is built for speed and even distribution rather than unpredictability. A token that protects an account needs a cryptographic source. Use a UUID for the record and something else for the secret.

Someone sent me an identifier. Can I tell what made it?

Partly, and that is what the inspection mode is for. You always get the version and the variant. From a version 1 or version 7 value you also get the moment it was created, and from a version 1 value the node field, which may be a hardware address. From a version 4 value you get nothing beyond the two markers, because the other 122 bits are random.

Does removing the hyphens change the value?

No. The hyphens carry no information, so the 32 character form holds exactly the same 128 bits as the 36 character one. It matters only for comparison: a text column will treat the two spellings as different strings, which is how one table ends up unable to match a value against itself.

Why does asking for ten version 5 identifiers give me one?

Because version 5 is a hash rather than a draw. The same namespace and the same name always produce the same result, so ten of them would be one value repeated ten times. Change the name and you get a different identifier; that is the only way to get more than one.

Should the column be a text type or a dedicated identifier type?

The dedicated type wherever the database offers one. It stores 16 bytes instead of 36 characters, normalizes case and hyphenation on the way in, and refuses anything that is not a valid identifier. A text column accepts all five formats above and every typo besides.

Related tools

UTM Link Generator

Builds a tracked campaign address and tells you which channel group the medium you typed will fall into - Open the generator

SEO Meta Tag Generator

Writes the head tags for a page and measures the title and description by rendered width rather than character count - Open the generator

QR Code Generator

Encodes text, an address, a network or a contact card into a scannable symbol, drawn in the page rather than fetched from anywhere - Open the generator

Barcode Generator

Produces a valid retail barcode with the check digit worked out, and explains what each part of the number means - Open the generator

Password Generator

The right tool for the job a UUID should not be given: a value that has to be unguessable rather than merely unique - Open the generator

Lorem Ipsum Generator

Filler copy for the same test fixtures these identifiers usually end up in, with a real word and character count - Open the generator

Generate 5 UUIDs in one go

Parameters