Generate secure UUIDs instantly with support for multiple UUID versions, batch generation and validation. Everything runs locally in your browser.
Random. 122 bits of cryptographically secure randomness.
UUIDs
Generate a UUID with one click.
The formatted output appears here — this is exactly what Copy all and Download produce.
Nothing generated yet
Generated in your browser with crypto.getRandomValues — nothing is uploaded.
Everything happens locally in your browser. Nothing is uploaded or stored.
What is a UUID?
A UUID — universally unique identifier — is a 128-bit value written as 32 hexadecimal digits in five hyphenated groups. It is standardised by RFC 9562, which replaced the long-serving RFC 4122 in May 2024 and added the versions most new systems now want.
The point of a UUID is not that it is long. It is that anyone can create one without asking anyone else. Two servers on opposite sides of the world, a phone that has been offline for a week and a batch job running at midnight can all mint identifiers independently and be confident they will never collide. No coordinator, no shared sequence, no round trip.
Not all 128 bits are free. Four of them record which version made the value, and two more record the variant — the family of standards it belongs to. You can read both straight out of the string:
Where the version and variant live
1550e8400-e29b-41d4-a716-4466554400002 ^ ^3 | └── variant: 8, 9, a or b means RFC 95624 └──────── version: 4 here
That leaves 122 bits for a v4 UUID to fill with randomness — which is where its uniqueness actually comes from.
How UUID generation works
Every version fills the same 16 bytes; they differ in what they put there. Two approaches exist, and the choice between them is the whole story.
Random. v4 asks the operating system for 122 secure random bits and stamps the version and variant over the rest. Uniqueness is probabilistic: there is no mechanism preventing a repeat, only odds so long that one has never been observed. This tool draws those bits from crypto.getRandomValues, the browser’s cryptographically secure generator. Math.random is not used anywhere in it — that generator is seeded predictably, and values built on it can be guessed.
Time based. v1, v6 and v7 put a clock reading in the value and fill the rest with randomness. Uniqueness is then structural as well as probabilistic: two values from the same generator differ because time moved, even before the random bits are considered.
That raises an obvious question — what happens when two are generated in the same millisecond? Each version answers differently:
v1 and v6 count in 100-nanosecond ticks, so a millisecond holds 10,000 distinct values. This tool advances that tick for every value in a batch, which is what makes a batch of 10,000 correct rather than 10,000 copies of the same identifier.
v7 stores plain milliseconds, so it leans on its 74 random bits instead. Turn on sequential generation and the 12 bits after the version become a counter, so values made in the same millisecond still come out in order.
One more detail matters for v1 and v6: the nodefield. It was designed to hold the machine’s MAC address, which made early v1 UUIDs a privacy problem — every value identified the computer that made it. RFC 9562 allows a random node instead, marked by setting the multicast bit, and that is what this tool does. The UUID validator will tell you whether a v1 value you paste in contains a real hardware address.
UUID versions explained
Four versions are worth generating today. They are genuinely different tools rather than settings on one tool.
v1 · Time based
Does not sort · Reveals when it was made
The original time-based version. It stores the low bits of the clock first, so v1 values do not sort into creation order — which is exactly the problem v6 was created to fix. Its node field was designed to hold a MAC address; here it is random with the multicast bit set, because a browser has no MAC address and publishing one would leak the machine.
v4 · Random
Does not sort · Reveals nothing
The one nearly everyone means by UUID. It carries no time, no machine identity and no ordering — just randomness, which is what makes it both unguessable and, as a database key, hard on an index. Use it unless you have a reason not to.
v6 · Time ordered
Sorts by creation time · Reveals when it was made
Field-for-field the same information as v1, with the timestamp written most-significant-first so lexical order matches chronological order. It exists as a migration path for systems already holding v1 values. New systems should prefer v7.
v7 · Unix time ordered
Sorts by creation time · Reveals when it was made
The modern choice for a database key. The leading timestamp means new values are always inserted at the right-hand edge of a B-tree index instead of scattered through it, which keeps writes cheap and the index compact — while the remaining random bits keep values unguessable.
The versions not listed are still valid, and the validator recognises them: v2 is a DCE security variant almost nobody uses, v3 and v5 derive a UUID from a name by hashing it — MD5 and SHA-1 respectively — so the same input always gives the same output, and v8 is a deliberately open slot for custom layouts.
If you want one rule: use v4 unless the identifier is a database key, in which case use v7. The next section explains why that second case is worth the exception.
UUID vs GUID
They are the same thing. GUID— globally unique identifier — is Microsoft’s name for the 128-bit value RFC 9562 calls a UUID, and the terms are used interchangeably. A GUID from .NET and a UUID from PostgreSQL are the same 16 bytes and interoperate without conversion.
What differs is convention, and occasionally something more:
Spelling. GUIDs are traditionally written in uppercase and wrapped in braces — {550E8400-E29B-41D4-A716-446655440000} — where UUIDs are lowercase and bare. Purely cosmetic; this tool reads and writes both.
Variant bits. Some older Microsoft GUIDs use the reserved Microsoft variant rather than the RFC one. The validator reports this, and it matters because a value with the wrong variant has no meaningful version number.
Byte order. This is the one that causes real bugs. .NET’s Guid.ToByteArray() writes the first three fields little-endian while the RFC specifies big-endian. Round-tripping a UUID through those bytes and back through a standards-compliant reader silently rearranges it.
So: treat UUID and GUID as synonyms in conversation, and check the byte order whenever one crosses a boundary between .NET and anything else.
When should you use UUIDs?
The question to ask is not “do I need something unique” — an auto-incrementing integer is unique. It is do I need identifiers that can be created without coordination. When the answer is yes, a UUID is the right tool. When it is no, an integer is smaller and faster.
Database primary keys
The main reason to choose a UUID: any client or service can mint one without asking the database first, which an auto-incrementing integer cannot do. Use v7 so the index stays cheap to write.
REST APIs
A resource identifier that appears in a URL should not be guessable, and a sequential integer is — /orders/1002 invites someone to try 1003. A v4 UUID removes that whole class of enumeration.
Microservices
When several services create records that end up in the same table, they need identifiers that cannot collide without a shared sequence. UUIDs let each service allocate independently and stay correct.
Session identifiers
Useful as a correlation handle, with one caveat: a session token that grants access should come from a purpose-built generator, not a UUID. Use one to identify a session, not to authenticate it.
Distributed systems
Two nodes that cannot reach each other still have to agree that their records are distinct. Independent generation is exactly the property a UUID provides, and it holds during a network partition.
Event tracking
Every event needs an identity so a retry can be recognised as a duplicate rather than counted twice. A v7 identifier also carries its own timestamp, which makes ordering a stream straightforward.
Idempotency keys
A client generates one before sending a request, so a retry after a timeout carries the same key and the server can tell a repeat from a new instruction. This only works if the client can mint it alone.
File and object names
Uploads from different users land in one bucket and must not overwrite each other. A UUID filename removes the collision without needing a lock, a counter or a round trip to check.
And where they are the wrong answer: a single-database application whose rows are only ever created by that database gains nothing and pays 16 bytes per row in every index. A UUID is also not a secret — it is unguessable, which is not the same thing as authenticated. Never let possession of an identifier stand in for permission to use it.
UUID best practices
Choosing a version
Default to v4. It reveals nothing, it is unguessable, and every language generates it out of the box.
Use v7 for database keys. The index behaviour below is the reason, and it is the single highest-impact choice on this page.
Use v6 only for compatibility with existing v1 data. For anything new, v7 is the better-specified option.
Avoid v1 for new work. Its layout does not sort, and its node field leaks a machine identity unless the generator deliberately randomises it.
Storage
Use a native type where one exists. PostgreSQL’s uuid is 16 bytes and compares as an integer would.
Otherwise use BINARY(16), not CHAR(36). The text form is 2.25 times the size, and that cost is paid again in every index containing the column. Reserve the readable form for tables small enough that ad-hoc queries matter more than bytes.
Store one canonical form. Lowercase, hyphenated, no braces. Normalise on the way in, so a lookup never misses because a value arrived wearing a different spelling.
Performance and indexing
This is where the version choice stops being academic. A B-tree index keeps its keys in sorted order, so where a new key lands decides how much work an insert costs.
Where each new row lands in the index
1v4 (random) │ ▓ ░ ▓ ░ ░ ▓ ░ ▓ ░ ▓ ░ ░ ▓ │ every insert hits a different page2v7 (time first) │ ░ ░ ░ ░ ░ ░ ░ ░ ░ ░ ░ ▓ ▓ │ inserts land together at the end
Random keys scatter writes. Each v4 insert touches a page that is probably not in memory, so the database reads it, splits it, and writes it back. Pages end up half full and the index grows larger than the data it indexes.
Time-ordered keys append. v7 inserts arrive at the right-hand edge of the index, on a page that is already in cache. Writes stay sequential and pages fill completely.
Do not index the text form. Comparing 36 characters where 16 bytes would do multiplies the cost of every comparison in every lookup.
Keep a separate sequential column if you need ordering. With v4 there is no creation order to recover; a timestamp column is the honest fix, and switching to v7 is the better one.
Security
Generate from a CSPRNG. A UUID built on Math.random is predictable, and predictable identifiers in URLs are enumerable.
Do not use a UUID as a session token or an API key. It is an identifier, not a credential. Use a purpose-built secret with its own length and rotation policy — the password generator will make one and tell you how much entropy it carries.
Remember that v1, v6 and v7 disclose a creation time.Usually harmless, occasionally not — it tells anyone holding the value when the record behind it was made, and a v7’s leading 48 bits are a plain Unix millisecond count that a timestamp converter turns into a date.
Frequently asked questions
Is this UUID Generator free?
Yes. Every version, batch generation up to 10,000 at a time, validation, the format options, search, copy and download are all free, with no account and no usage cap.
Are generated UUIDs truly unique?
In practice, yes — but the guarantee is statistical rather than absolute. A v4 UUID carries 122 random bits, which is about 5.3 undecillion possible values. You would need to generate roughly 2.7 quintillion of them before a single collision became as likely as not, and at a billion per second that takes about 86 years. The time-based versions are stronger still, because two values from the same generator also differ in their timestamp.
Which UUID version should I use?
v4 unless you have a reason not to — it is unguessable, carries no information about your systems, and is what every library gives you by default. Choose v7 when the identifier is a database primary key, because its leading timestamp keeps index writes cheap. Choose v6 only when you already have v1 values and need new ones that sort alongside them. There is very little reason to choose v1 for new work.
What is the difference between UUID and GUID?
Nothing, at the level of the bits. GUID is Microsoft's name for the same 128-bit identifier defined by RFC 9562, and the two terms are interchangeable. The differences are conventions: GUIDs are traditionally written in uppercase and wrapped in braces, and some older Microsoft GUIDs use a different variant bit pattern or store their first three fields little-endian. This tool accepts all of those spellings and tells you which variant a value actually carries.
Can I generate multiple UUIDs at once?
Yes, up to 10,000 in a single batch, with presets for 1, 10, 25, 50 and 100 and a box for any number in between. A full batch takes a few milliseconds. All of them are generated from one call to the browser's secure random source rather than one call each, which is what keeps it fast.
Can I validate existing UUIDs?
Yes. Paste any UUID into the Validate panel and it reports whether it is well formed, which version and variant it carries, and how it was written — uppercase, braced, quoted, missing hyphens, or in urn:uuid form. If it is not valid, the exact characters at fault are underlined. For v1, v6 and v7 it also decodes the creation time embedded in the value.
Can I download generated UUIDs?
Yes, as TXT, CSV or JSON. The download always matches exactly what the Output panel shows, so what you see is what lands in the file. The filename records the version and the count.
Does this tool work offline?
Once the page has loaded, yes. Generation, validation and formatting are all local, so you can disconnect and keep working. A connection is only needed to load the page in the first place.
Are these UUIDs cryptographically secure?
The randomness is. Every random bit comes from crypto.getRandomValues, the browser's cryptographically secure generator — Math.random is not used anywhere in this tool, because it is seeded predictably and would make values guessable. That said, a v4 UUID is an identifier, not a secret: it is fine as an unguessable URL component, but a session token or an API key should come from a purpose-built generator with a documented threat model.
Is anything sent to a server?
No. UUIDs are generated by JavaScript running on your own machine and never leave it. Nothing is uploaded, stored or logged — which matters, because a UUID you generate on a website that logs it is no longer an identifier only you know about.
Why is UUID v7 better for database keys?
Because of how B-tree indexes work. A v4 UUID is random, so each new row lands at an unpredictable point in the index, touching a different page every time and scattering writes across the whole structure. A v7 UUID starts with a timestamp, so new rows always append at the right-hand edge — one hot page, sequential writes, far less fragmentation. On a large table the difference in insert throughput is substantial, and the index stays smaller too.
How should I store a UUID in a database?
Use a native UUID type if your database has one — PostgreSQL's uuid is 16 bytes. If not, store the raw 16 bytes in a BINARY(16) column rather than a 36-character string: the text form is more than twice the size, and that cost is paid again in every index that includes the column. Store it as CHAR(36) only when you need the value readable in ad-hoc queries and the table is small enough for it not to matter.
Can a UUID reveal information about my system?
A v1 UUID can. Its node field was designed to hold a MAC address, so a v1 value generated by a typical library identifies the machine that made it and links together every other UUID that machine produced. Its timestamp reveals creation time to 100-nanosecond precision. This tool always uses a random node with the multicast bit set, and the validator tells you whether a v1 value you paste in contains a real hardware address. v4 reveals nothing; v6 and v7 reveal the time but not the machine.
What are the nil and max UUIDs?
The nil UUID is all zeroes and the max UUID is all ones. Both are valid and both are reserved as sentinels — the nil one conventionally means “no value”. Neither should be used as a real identifier, and a nil UUID turning up in your data usually means a variable was never assigned rather than that something was deliberately marked empty.
Should I use a UUID as a primary key at all?
It depends on whether you need identifiers that can be created without coordination. That is the real advantage: any service, client or offline device can mint one and be confident it will not clash, which an auto-incrementing integer cannot do. The costs are size — 16 bytes against 4 or 8, multiplied by every index — and, for v4, index fragmentation. If everything is written by one database and identifiers may be sequential, an integer is still the simpler choice.
Keep going
Tools that pair with this one
Same privacy model — everything below runs in your browser too.
