UUID Generator
Every Version, in Bulk, With a Checker

Jobs This UUID Generator Handles for You

This UUID generator makes unique IDs for databases, APIs, files and tests. Choose a version and a count, and the IDs show up instantly. From there, copy the list or keep it as a text file.

It covers every version in use today. Version 4 is pure random, version 7 sorts by time, and versions 3 and 5 turn a name into the same ID every time. There are also the older versions 1 and 6, and the special nil and max values.

The page also works the other way round. Paste any UUID, and the checker tells you its version and variant, and for time-based ones, the exact moment it was made.

What Is a UUID?

Every UUID, or universally unique identifier, is one 128-bit value. It is usually written as 32 hex digits in five groups, such as 017f22e2-79b0-7cc3-98c4-dc0c0c07398f. Because there are so many possible values, anyone can make one without asking a central server, and it will not clash with anyone else’s.

Two small parts tell you what kind of UUID it is. The third group opens with the version digit, and the fourth group opens with the variant. Everything else is time, randomness or a hash, depending on the version.

Picking the Right UUID Version for Your Project

For most jobs, use version 4. It is random, simple and supported everywhere. However, if the IDs become keys in a database table, choose version 7 instead. It starts with the time, so new rows are stored in order, which keeps inserts fast.

When the same thing must always get the same ID, use version 5. For example, a URL or an email address can be turned into a stable UUID that any system can recreate. Versions 1, 3 and 6 are mainly there for older systems that expect them.

Why Postgres and MySQL Indexes Like UUID v7

Random version 4 IDs land all over a database index, so every insert touches a different page. Over time, that slows writes and wastes memory. By contrast, UUID v7 begins with a millisecond timestamp, so each new ID lands at the end of the index, much like an auto-increment number.

This generator also keeps a batch in order. When many IDs share one millisecond, a counter in the next 12 bits keeps them sorted, just as RFC 9562, the UUID standard, recommends.

UUIDs Built From a Name: v3 and v5

Name-based UUIDs are made from two inputs: a namespace, which is itself a UUID, and a name. Both go through a hash, which is why identical inputs always produce the identical UUID. There are standard namespaces for domain names, URLs, OIDs and X.500 names, and you can also use your own.

Version 5 uses SHA-1 and version 3 uses MD5. Neither hash guards anything here. Both only spread the bits evenly. Still, choose version 5 for new work, since the standard prefers it.

Read Any UUID With the Checker

Paste a UUID into the checker and it splits apart at once. You see the standard form, the variant and the version. Versions 1, 6 and 7 also carry a timestamp. The checker shows that moment in UTC and in your own time zone.

For version 1 and 6, it also shows the clock sequence and the node. The node used to be the network card address of the computer that made it, so the checker tells you whether it looks real or random. Click any UUID in the generated list to check it too.

Check a Whole List With the UUID Validator

One UUID at a time is fine until you have four hundred of them. Instead, paste the whole list into the UUID validator and every line gets its own verdict. The page splits on spaces, commas, semicolons, pipes and line breaks. So a spreadsheet column, a JSON array and a SQL result all paste in as they are. It reads up to 5,000 IDs in one go. Anything past that count shows as skipped rather than dropping quietly.

Notably, there are three verdicts here, not two. A row counts as valid when the standard describes it. It counts as invalid when it is not a UUID at all. Between those sits the note, for a row with a correct shape that still deserves a look. For example, an old Microsoft or NCS variant is a real UUID that real systems still emit. Those two variants come from RFC 4122, the older UUID standard. Then there is the RFC variant carrying a version number nobody has assigned yet, which gets a note too. Calling any of those invalid would be a lie, because working systems hand them out every day.

Also, every rejected row says why. A line in a list can fail to read in only three ways. It holds a character outside 0-9, a-f and the hyphen. It has the wrong number of hex digits. Or it has all 32 digits with the hyphens in the wrong places. The first two usually mean a copy that caught a stray character, or one that clipped a digit mid-paste. The third is a UUID whose hyphens sit somewhere other than after the 8th, 12th, 16th and 20th digit. The row says exactly that. Blank lines are not errors at all, because the list skips them before the count begins.

Wrapping comes off before the check, because real lists arrive wrapped. The page strips quotes, backticks, square brackets, angle brackets, round brackets and a trailing colon or full stop. It strips the urn:uuid: prefix too. Curly braces get more care than that. A Microsoft GUID in braces reads whole, while a stray brace from a JSON object simply goes. In addition, a bare run of 32 hex digits with no hyphens still reads. So does any mix of capital and small letters. A word that was never an ID, such as a JSON key, still gets its own row rather than disappearing. That way the count stays honest about everything in the paste.

Next, the validator looks for duplicates across the whole list. The comparison runs on the canonical form. So {X}, urn:uuid:X and the same ID in capitals all count as one. The repeated row then points back to the line it first appeared on. Two identical junk lines, on the other hand, never count as duplicates. A row that is not a UUID has no canonical form to compare. After that, the summary counts the list for you. You see how many lines went through, and how many the standard describes. Three more counts cover the rows worth a look, the rows that are not UUIDs at all and the repeats.

Those counts stay apart on purpose, and the reason matters. A noted row has a correct shape rather than a broken one. Folding it into one pass-or-fail number would hide the only thing worth noticing about it. However, if you only want the problems, the filter leaves the rows that are not UUIDs in view. Noted rows keep their place and their reason. Finally, the report copies out whatever the screen shows, so the list can go straight into a ticket.

UUID or GUID?

Both names describe one identical thing. GUID stands for globally unique identifier, the Microsoft term for a UUID. So this page works as a GUID generator too: turn on capital letters and curly braces, and you get the {XXXXXXXX-XXXX-...} style that Windows and .NET often show.

Very old GUIDs from COM used a different variant. The checker spots those and labels them, so you know when an ID came from that older scheme.

The Real Odds of Two Random UUIDs Matching

Of the 128 bits in a v4 UUID, 122 are random. So you would need about 2.7 quintillion IDs before the chance of one repeat reaches 50%. In practice, a bug in your own code is far more likely than a repeat.

Time-based versions use fewer random bits, but they add the time. As a result, two IDs can only clash if they are made in the same millisecond and also draw the same random bits. The Wikipedia article on UUIDs works through the numbers in detail.

UUIDs or Auto-Increment Numbers?

Auto-increment IDs are short and fast, but they have limits. First, only the database can hand them out, so an app must wait for an insert before it knows the ID. Second, they leak information, because order 1043 tells anyone that you have about a thousand orders.

UUIDs solve both problems. Any server, phone or browser can make one offline, and the IDs from different systems can be merged without clashes. On the other hand, they take more space, which is why version 7 and binary storage matter on large tables.

UUIDs in Your Code

The format switches cover the common needs. Remove the hyphens for compact storage, add the urn:uuid: prefix for XML and RDF, or wrap each ID in quotes with commas, ready to paste into an array or a SQL list.

Most databases have a native type for UUIDs. PostgreSQL has uuid, SQL Server has uniqueidentifier, and in MySQL the usual choice is BINARY(16). For timestamps inside your data, our Unix timestamp converter turns them into dates and back.

Can You Rely on These UUIDs in Production?

Yes. The random bits come from your browser’s secure random source, the Web Crypto getRandomValues function, which is built for keys and tokens. Nothing is sent to our server, so no one else ever sees the IDs you make.

Remember that a UUID is an ID, not a secret. Whoever sees a UUID can reuse it. For passwords and API keys, use our password generator instead.