About the UUID Generator
A UUID is a 128-bit number written as 32 hexadecimal digits in five hyphenated groups. Its purpose is to let separate machines mint identifiers that will not collide without ever talking to each other - no central sequence, no coordination, no lock. That property is why UUIDs turn up as primary keys, request identifiers, idempotency keys, file names, and trace IDs.
This generator produces three formats: UUID version 4, which is entirely random; UUID version 7, which puts a timestamp at the front so identifiers sort in creation order; and nanoid, a shorter URL-safe alternative that is not a UUID at all. You can generate up to 100 at once, which is the usual reason to open a page like this - seeding a table, filling a fixture file, or writing a migration.
Everything is generated in your browser using the operating system's cryptographic random number generator. Nothing is requested from a server, so no two visitors can ever receive the same identifier from us, and the values you copy have never left your machine.
How to use this tool
- Pick a format. Version 4 is the safe default; choose version 7 if the identifiers will become database keys.
- Set how many you need. One is the default and 100 is the maximum.
- Optionally switch on uppercase or turn off hyphens. Both toggles are disabled for nanoid, because its alphabet is case-sensitive and already contains hyphens.
- Press Generate for a fresh batch. Every press produces entirely new values.
- Use Copy all to put the whole list on your clipboard, one identifier per line.
Version 4: random, and almost always the right answer
A version 4 UUID is 122 random bits with six bits spent on a version marker and a variant marker. Those fixed bits are why every v4 has a 4 at the start of the third group and one of 8, 9, a, or b at the start of the fourth - if the identifier in front of you does not, it is not a v4.
122 random bits is a genuinely enormous space. To reach a one-in-a-billion chance of a single collision you would need to generate around 100 trillion of them. In practice a v4 collision is not a risk worth designing around; the realistic failure mode is not collision but a weak random source, which is why this tool uses the platform's cryptographic generator rather than Math.random.
Version 7: the same idea, but friendly to a database index
Version 7 was standardised in RFC 9562 in 2024 to solve a problem v4 causes when it is used as a primary key. Because v4 values are random, consecutive inserts land at random positions in the index's B-tree. The tree cannot keep appending to one page, so it splits pages repeatedly, the working set stops fitting in memory, and insert throughput degrades as the table grows. Teams often discover this only once the table is large enough that fixing it is expensive.
A version 7 UUID replaces the first 48 bits with the Unix timestamp in milliseconds, followed by 74 random bits. Because the timestamp leads, sorting the identifiers as text or as bytes sorts them by creation time, and new rows append to the right-hand edge of the index the way an auto-incrementing integer would. You keep the decentralised generation of a UUID and get back the locality of a sequence.
The trade-off is that a v7 tells anyone holding it roughly when it was created, to the millisecond. For a database key that is usually irrelevant or even useful. For a password reset token or a public share link it is an information leak, and v4 is the better choice.
Why versions 1, 3, and 5 are not offered here
Version 1 also embeds a timestamp, but it pairs it with the network card's MAC address. That means a v1 UUID can identify the physical machine that produced it, which has been used in real forensic investigations. Version 7 gives you time ordering without that disclosure, and it is the reason v1 should be considered retired for new work.
Versions 3 and 5 are different in kind: they are hashes of a name within a namespace, so the same input always yields the same UUID. They are useful for deriving a stable identifier from something you already have, but they need two inputs rather than a button, and they are not random. A generator page is the wrong shape for them.
nanoid: shorter, when the identifier will be seen
nanoid is not a UUID. It is 21 characters drawn from a 64-character URL-safe alphabet, giving about 126 bits of randomness - marginally more than a v4 - in 21 characters instead of 36. It needs no percent-encoding in a URL, no quoting in a shell, and it survives a double-click selection intact, which hyphenated UUIDs do not in some editors.
That makes it a good fit for anything a human will see or type: short links, invite codes, document slugs, filenames. It is a poor fit where something else expects a UUID specifically - a Postgres uuid column, a protocol field, an API contract - because it is not one and will be rejected.
The alphabet includes both hyphen and underscore and it is case-sensitive, so changing the case or removing the hyphens from a nanoid produces a different identifier rather than a restyled one. This tool disables both options when nanoid is selected for exactly that reason.
Frequently asked questions
- Are these UUIDs actually unique?
- They are unique in the practical sense that matters. Uniqueness is probabilistic rather than guaranteed, but with 122 random bits from a cryptographic source the probability of a repeat is far below the probability of a disk or memory error corrupting the value instead. The one thing that would undermine it is a weak random source, which is why this page uses the browser's crypto API rather than Math.random.
- Should I use version 4 or version 7 for a database primary key?
- Version 7, in almost every case. Random v4 keys scatter inserts across the index and cause page splits that get worse as the table grows, while v7's leading timestamp makes inserts append in order. Use v4 instead when the identifier is public and the creation time is sensitive, such as a reset token or an unguessable share link.
- Can someone work out when a version 7 UUID was created?
- Yes, to the millisecond - the first twelve hexadecimal digits are the Unix timestamp in milliseconds and anyone can read them. That is the deliberate design of the format, not a flaw, but it means v7 is the wrong choice anywhere the creation time should stay private.
- Is uppercase or lowercase correct?
- Lowercase is what RFC 9562 specifies for output, and it is what this tool produces by default. Parsers are required to accept either, so uppercase is safe to consume, and the uppercase toggle exists because some systems - certain Windows registry conventions and older enterprise schemas - display or expect it that way. Pick one and stay consistent, since a naive string comparison will treat the two cases as different values.