UUID Generator

Q: Which UUID version should I use?

Version 4 for general use — it is the default nearly everywhere and encodes nothing about its origin. Version 7 when the UUID is a database primary key, because its leading timestamp makes inserts append to the index instead of scattering across it. Version 1 only when something you cannot change requires it; it is legacy, it can leak a machine address, and v7 does the time-ordering job better. Versions 3 and 5 solve a different problem entirely — deterministic UUIDs derived from a name — and are not generated here.

Q: What makes v7 better for database keys?

Clustered indexes store rows in key order. A v4 key is random, so each insert lands in an arbitrary position, forcing the database to split and rewrite pages — and the bigger the table, the worse it gets. A v7 key begins with a millisecond timestamp, so new rows sort to the end and inserts append, which is the same access pattern an auto-increment integer gives you. You keep global uniqueness and the ability to generate keys client-side, without the write amplification.

Q: Can two UUIDs ever collide?

In principle yes, in practice no, provided they come from a proper random source. A version 4 UUID has 122 random bits — around 5.3 undecillion possibilities. You would need to generate roughly a billion per second for about 85 years to reach a one-in-a-billion chance of a single collision. The real collision risk is not the maths but the source: UUIDs generated with a weak or badly seeded random number generator can and do collide.

Q: Are UUIDs secure or secret?

No. They are designed to be unique, not unguessable. A v4 UUID from a cryptographic source is in practice unguessable, but a v1 or v7 one is not — both encode their creation time, so an attacker who knows roughly when a record was made has narrowed the search enormously. Never use a UUID as a session token, an API key or a password-reset link. Use a purpose-built random token instead.

Q: What is the nil UUID?

All 128 bits set to zero — 00000000-0000-0000-0000-000000000000. It is the standard 'no value' UUID, used the way null is used, and it is never produced by any generator. Its counterpart is the max UUID, all f's, defined as a sentinel at the opposite end of the sort order. Finding a nil UUID in real data almost always means an uninitialised variable rather than a deliberate value.

Q: Should I store UUIDs as text or binary?

Binary, where your database supports it. Postgres has a native uuid type; SQL Server has uniqueidentifier; MySQL can use BINARY(16) with UUID_TO_BIN. Each stores 16 bytes rather than the 36 characters of the hyphenated string, which more than halves the index size and speeds up every comparison. If you must use text, store it consistently — lowercase, hyphenated, no braces — so that string equality does not silently fail.

Generate v4, v7 and v1 UUIDs in bulk, and inspect any UUID to see its version and creation time.

Version

How many

Hyphens Uppercase Braces

Inspect a UUID

What It Does

This tool generates UUIDs in the version you need and explains what that choice costs you. Version 4 is pure randomness; version 7 puts a timestamp in the leading bits so identifiers sort by creation time, which is what stops a UUID primary key wrecking database write performance; version 1 is the legacy format that embeds a machine identifier. It also works in reverse: paste any UUID and it will tell you its version, its variant and, where the format carries one, exactly when it was created.

When to Use It

You need identifiers for database rows and want to pick between v4 and v7 knowingly.
You are seeding test data and need a few hundred unique identifiers as JSON or CSV.
You found a UUID in a log and want to know when it was created and what generated it.
You need a correlation ID for tracing a request across services.

Worked Examples

Ten v7 UUIDs, in order

Look at the output: the leading characters are nearly identical and increase down the list, because the first 48 bits are the timestamp. That is why v7 sorts chronologically as plain text — and why it behaves well as a database key.

Ten v4 UUIDs, for comparison

Same tool, no pattern at all. Every one starts differently because 122 of the 128 bits are random. Excellent for unguessability, poor for a clustered index.

Inspect a UUID with a hidden timestamp

A v7 UUID. The inspector pulls the creation time back out of the leading bits and shows it in your own timezone — worth remembering if the identifier is publicly visible and creation time is something you would rather not publish.

The nil UUID

All zeros. It is the conventional 'no value' UUID and is never randomly generated, so seeing one in your data almost always means an uninitialised variable rather than a real identifier.

Common Mistakes

Using v4 as a clustered primary key on a large table. Random values scatter inserts across the whole index, causing page splits and steadily worse write performance as the table grows. This is the specific problem v7 was created to solve — use it, or keep an auto-increment key and treat the UUID as a secondary identifier.
Generating UUIDs with Math.random. It is not a cryptographic source and its output is predictable from previous values, so identifiers can be guessed. This tool uses crypto.getRandomValues; so should your code.
Assuming UUIDs are secret. They are unique, not unguessable-by-design in every version — v1 and v7 both encode a timestamp, and v1 may encode a machine address. Never use a UUID as a bearer token or a password-reset key.
Storing a UUID as a 36-character string when your database has a native type. Postgres has uuid and MySQL can use BINARY(16); both take 16 bytes instead of 36 and index far better.
Treating a v1 UUID's node field as anonymous. It is meant to be the MAC address of the generating machine, which is exactly why v1 fell out of favour — it can identify the hardware that produced the identifier.

Features

v4 random

v7 time-ordered and v1 legacy

Bulk generation up to 1000 at a time

Uppercase

braces and no-hyphen formats

Copy as plain list

JSON array or CSV

Download as a text file

Inspector that decodes version

variant and creation time

Detects nil and max sentinel UUIDs

Warns when a v1 node looks like a real MAC address

Uses crypto.getRandomValues

never Math.random

Runs entirely in your browser

How to Use

1. Pick a version — v4 unless you are choosing a database key, in which case consider v7. 2. Set how many you need and hit Generate. 3. Adjust the format toggles; these re-format the same UUIDs rather than generating new ones. 4. Copy in whichever shape you need, or download as a file. 5. Paste any UUID into the inspector at the bottom to decode it.

Frequently Asked Questions

Which UUID version should I use?

What makes v7 better for database keys?

Can two UUIDs ever collide?

Are UUIDs secure or secret?

What is the nil UUID?

Should I store UUIDs as text or binary?

Embed this UUID Generator

Paste this snippet into your site to embed the tool.

<iframe src="https://webtoolworld.com/embed/uuid-generator" style="width:100%;min-height:560px;border:0" loading="lazy" title="UUID Generator"></iframe>
<p style="font-size:12px;margin-top:6px"><a href="https://webtoolworld.com/uuid-generator">UUID Generator</a> by WebToolWorld</p>

Everything is generated in your browser using crypto.getRandomValues, the same source your language's secure random API uses. Nothing is requested from a server, which matters for identifiers: a UUID handed to you by someone else's server is a value they have seen. UUIDs are designed to be unique, not secret — v1 and v7 both encode their creation time, and v1 may encode the generating machine's MAC address. Do not use any UUID as a security token.