Random Uuid Generator

What the random UUID generator does

You need an identifier. A row in a table, a file on disk, a request passing through four services that have never spoken to each other, a test fixture you will delete in an hour.

This gives you one. Or a hundred, if you are seeding something.

What follows is the interesting part. Why a thing like this had to be invented, what the odds actually are, and the time one of these got somebody arrested.

How to use it

1. Choose how many you want. Anywhere from 1 to 100.
2. Press Generate. A fresh set every time.
3. Press Copy to take the whole set with you.

A number that has to be unique with nobody in charge

Start with the ordinary way to make an identifier. You count. One, two, three. Your database does it, your ticket system does it, the deli counter does it.

Counting works because something is doing the counting. There is one deli, one machine, one place where the number lives, and it hands out the next one when asked. Take away that single place and counting stops working immediately. Two machines both say 47. Now you have two things called 47 and no way to tell which is which.

So the obvious fix is to keep a central authority. One service that hands out numbers, and everyone asks it politely. Which is fine until that service is on another continent, or is down, or the thing needing an identifier is a phone in a tunnel with no signal that will sync when it surfaces.

Here is the problem stated properly. You need every machine to be able to invent an identifier, at any moment, without asking anyone, without telling anyone, without ever having met the other machines, and for those identifiers to still never collide.

Written like that, it sounds impossible. It is not impossible. It is just a bet.

The trick is to stop trying to guarantee uniqueness and start trying to make collision so unlikely that the difference does not matter. Make the number enormous. Fill it with randomness. Then the odds do the work that a central authority used to do.

That is the whole idea, and it is one of those ideas that looks like cheating until you look at the arithmetic.

The odds you will ever see the same one twice

A UUID is 128 bits. Six of those bits are spoken for, because they record which kind of UUID it is and which standard it follows. That leaves 122 bits of pure randomness.

Two to the power of 122 is a number with 37 digits in front of it. Writing it out does not help. Nobody has intuition for 37 digits.

So try it the other way, from the side that actually matters.

You do not need to generate every possible UUID to hit a collision. You only need two of them to match, anywhere in the pile, and that is a much easier target than it sounds. It is the same reason twenty-three people in a room gives you even odds that two share a birthday, which feels wrong every single time you hear it and is nevertheless true. Matching any pair is far easier than matching one specific value.

Even with that working against you, the answer comes out absurd. You would need to generate around a billion UUIDs every second, without stopping, for roughly eighty-five years, before you reached a coin-flip's chance of ever having produced the same one twice.

Not a certainty. A fifty-fifty.

This is why nobody bothers checking. Not because checking is hard, but because the check would never fire. Engineers talk about UUIDs being "practically unique" and the word doing the work in that phrase is practically. It is not a guarantee. It is a bet at odds so long that the universe runs out of patience before the bet does.

The virus that a serial number caught

On 26 March 1999 a Word document called list.doc appeared on a newsgroup, promising free passwords to adult websites. Opening it in Word ran a macro. The macro opened Outlook, took the first fifty addresses out of the address book, and mailed itself to all of them. Then it did the same on each of those machines.

Melissa was, at the time, the fastest-spreading thing the internet had ever seen. Companies shut their mail servers off to stop it. The damage ran to tens of millions of dollars.

And there was a man in Massachusetts who knew something about Word documents.

Richard Smith ran a company called Phar Lap Software, and he had recently made himself unpopular at Microsoft by pointing out that every Office document quietly carried an identifier, and that the identifier was not as meaningless as it looked. Part of it was derived from the network card of the machine that made the file. A serial number, burned into a piece of hardware, sitting inside every document that machine had ever produced.

Which meant documents could be matched to each other. And to a machine.

Smith pulled the identifier out of list.doc and posted it. A researcher in Sweden pointed him at a virus author who went by VicodinES. The identifiers matched. Same machine.

Then it went sideways, and the sideways part is the part worth keeping.

VicodinES had not written Melissa. The identifier records the machine that created a document, not the machine that later edits it, and virus writers borrow from each other constantly. Melissa's author had started from someone else's file and typed over it, and the original creator's fingerprint had come along for the ride. The number was pointing at the wrong man with total confidence.

What actually found David L. Smith was more ordinary. A tip from AOL, an account, and an internet provider's logs from the day the thing appeared. He was arrested on 1 April 1999, six days after the release, and served twenty months.

But look at what that identifier did. It was supposed to be a meaningless serial number. Instead it was carrying a hardware address around inside every file, well enough to link documents to a machine, and badly enough to accuse the wrong person. Both of those are the same fact: the number meant something, and nobody had decided it should.

That is the argument for randomness, made in public, in 1999. An identifier that is derived from anything can be read backwards. An identifier that is nothing but noise cannot.

Why this one is a version 4

UUIDs come in versions, and the version is not a release number. It is a recipe. Version 4 means this one was made out of randomness and nothing else.

The original recipe, version 1, was built the sensible way: take the current time, add a counter, add the machine's network address so that no two machines could ever collide. Perfectly logical. It is also exactly the thing Richard Smith took apart, because a version 1 UUID tells you when it was made and which machine made it, to anyone who cares to look. It solved uniqueness by making every identifier a small confession.

Version 4 throws all of that away. No clock, no hardware, no counter, no history. Just 122 bits of noise. It cannot leak your machine because it never knew your machine. It cannot be guessed by someone who knows roughly when you made it, because it does not know either. Two of them made a second apart on the same computer have nothing whatsoever in common.

The trade is that a version 4 knows nothing about itself, which is precisely why you would choose it.

There are others. Versions 3 and 5 are for when you want the same input to always produce the same identifier. Versions 6, 7 and 8 arrived in 2024 when the standard was rewritten, and version 7 is the interesting newcomer: it puts a timestamp back at the front, deliberately, so a pile of them sorts into the order they were made. That is a real problem it is solving, one that matters if you are using identifiers as the sort key in a large database.

Different jobs. Version 4 is the one you want when you want an identifier that is unguessable, unlinkable, and carries no story about where it came from.

You can read the version straight off the string. The digit at the start of the third group is the version number. On every UUID above, it is a 4.

Where these come from

These are made in your browser, by your browser, using the cryptographic random number source your operating system provides. Not the ordinary random function that shuffles a list. The one intended for things that must not be predictable.

The generation itself is handled by the uuid library, which is the reference implementation most of the JavaScript world uses, and it checks its own output before handing it back.

Nothing is sent anywhere. Every identifier on this page was invented on your machine and is overwhelmingly unlikely to have ever existed before.

Questions people ask

Is a GUID the same thing as a UUID?

Yes. GUID is what Microsoft called them and the name stuck in the Windows and .NET world. Same 128 bits, same format, same standard. If a library asks for a GUID, give it a UUID.

Why is there always a 4 in the same place?

That is the version, and it is stored in the identifier rather than assumed. Anything reading a UUID can look at that digit and know how the thing was made without being told. The character right after the third hyphen carries similar information about which family of the standard it belongs to, which is why it is always an 8, 9, a or b.

Are these safe to use as a password reset token or an API key?

The randomness underneath is the cryptographic kind, which is the part most people get wrong. The thing to remember is what a UUID is for: it is an identifier, and identifiers get logged, printed in URLs, and pasted into support tickets. If something is meant to be a secret, treat it like a secret, whatever it was made from.

Does uppercase or lowercase matter?

The characters are hexadecimal, so both mean the same value and anything reading a UUID should accept either. The convention is lowercase.

Should I use one as a primary key?

People do, constantly, and it buys you something real: you can create a record and know its identifier before it ever reaches the database, which makes offline work and distributed writes far simpler. The thing worth knowing is that a version 4 lands in a random position in an index every time, which is the exact problem version 7 was designed for. If your table is small, it will never matter. If it is enormous and write-heavy, it is worth reading about.

Can I get the same one twice?

See above. You would need a billion a second for eighty-five years to have even odds of it, and that is across every UUID ever made by anyone.

References

1. Davis, K., Peabody, B. and Leach, P. (2024). Universally Unique IDentifiers (UUIDs). RFC 9562, Internet Engineering Task Force. https://doi.org/10.17487/RFC9562
2. Leach, P., Mealling, M. and Salz, R. (2005). A Universally Unique IDentifier (UUID) URN Namespace. RFC 4122, Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/rfc4122
3. Federal Bureau of Investigation. The Melissa Virus. Famous Cases and Criminals. https://www.fbi.gov/history/famous-cases/melissa-virus
4. Newsweek (1999). Biting back at the wily Melissa. https://www.newsweek.com/biting-back-wily-melissa-164670
5. The Baltimore Sun (1999). N.J. man charged in computer virus. https://www.baltimoresun.com/1999/04/03/nj-man-charged-in-computer-virus-melissa-bug-preys-on-e-mail-systems-around-the-world/