UUID Generator (v4 and v7)
Generate UUIDs one at a time or a thousand at once. Version 4 is the familiar random identifier; version 7 is the newer time-ordered variant that solves the database index problem v4 causes.
- Free, no sign-up
- Runs in your browser
- Nothing uploaded
- Updated Sep 2026
—
At a glance
- Versions
- v4 (random) and v7 (time-ordered, RFC 9562)
- Randomness
crypto.getRandomValues— the browser's CSPRNG- Bulk
- Up to 1,000 at once
- Formats
- Standard, uppercase, no hyphens, quoted, as a list
- Collision
- Negligible — 122 random bits in v4
- Processing
- Entirely client-side
v4 or v7 — the choice that matters
UUID v4 is 122 bits of randomness. It has been the default for two decades and is entirely fine for identifiers that are not database primary keys.
UUID v7, standardised in RFC 9562 in 2024, puts a millisecond timestamp in the first 48 bits and fills the rest with randomness. That one change makes them sort chronologically, which matters more than it sounds.
The problem v7 solves is database index fragmentation. A B-tree index — which is what your primary key uses — performs best when new values are appended at the end. Random v4 values land anywhere in the index, causing page splits, poor cache locality and steadily worsening insert performance as the table grows. On a large table with heavy inserts, the difference is substantial. v7 values increase over time, so inserts append, exactly like an auto-incrementing integer but without needing a central sequence.
The practical rule: use v7 for database primary keys, especially in insert-heavy tables. Use v4 when the identifier must reveal nothing, since a v7 discloses roughly when it was created. Session tokens, password reset links and anything where creation time is sensitive should stay v4 — or better, not be a UUID at all.
Are collisions a real risk?
No, provided the randomness is genuine. A v4 UUID has 122 random bits, giving about 5.3 × 10³⁶ possible values. To reach a one-in-a-billion chance of a single collision you would need to generate around 100 trillion of them. For any application, this is not a risk worth engineering around.
The real risk is a bad random source. Math.random() is not cryptographically
secure and is seeded predictably in some environments; UUIDs built on it can be guessable,
which matters enormously if they are used as session tokens or unguessable URLs. This tool
uses crypto.getRandomValues(), the browser's cryptographically secure generator,
and prefers the native crypto.randomUUID() where available.
A related caution: a UUID being unguessable in practice does not make it a secret. Treating an unguessable URL as an access control mechanism is fragile — identifiers leak through referrer headers, browser history, analytics, chat logs and screenshots. Use real authorisation for anything that matters.
Storing UUIDs efficiently
A UUID is 128 bits — 16 bytes. Its canonical text form is 36 characters, and storing that
as a VARCHAR(36) is the most common mistake in UUID adoption.
The cost compounds. Thirty-six bytes instead of sixteen is more than double on the column itself, but the primary key is copied into every secondary index and every foreign key referencing the table. On a large schema that difference in storage and index size translates directly into less of your working set fitting in memory.
Use the native type where one exists: UUID in PostgreSQL,
BINARY(16) in MySQL, UNIQUEIDENTIFIER in SQL Server. Each stores the
128 bits directly. If you must use a string column, at least drop the hyphens for 32 characters
and use a fixed-width CHAR rather than VARCHAR.
One MySQL-specific note: if you are storing v4 UUIDs as the primary key in InnoDB, the combination of random ordering and clustered indexes is particularly costly. That is the exact situation v7 was designed for, and switching is usually the single highest-value change available.
How to use the UUID Generator
-
Choose a version
v7 for database primary keys. v4 when the identifier must not reveal its creation time.
-
Set how many you need
One, or up to a thousand for seeding test data or a migration.
-
Pick a format
Standard hyphenated is canonical. No-hyphen suits compact storage; quoted and comma-separated suits pasting into code or SQL.
-
Copy or download
Copy the list, or download it as a text file for larger batches.
Frequently asked questions
What is the difference between UUID v4 and v7?
v4 is entirely random. v7 begins with a millisecond timestamp, so values sort chronologically. That makes v7 much better as a database primary key, because inserts append to the index rather than landing randomly in it. The trade-off is that a v7 reveals roughly when it was created.
Can two UUIDs ever be the same?
Practically never with a proper random source. v4 has 122 random bits; you would need to generate around 100 trillion before a one-in-a-billion collision chance. The real risk is a weak random generator, not the maths — this tool uses the browser's cryptographic source.
Should I use a UUID as a primary key?
It is a reasonable choice when IDs must be generated in several places without coordination, or must not reveal row counts. Use v7 rather than v4, store it in a native 16-byte type, and be aware you are trading some index efficiency for those properties.
How should I store a UUID in a database?
In the native type — UUID in PostgreSQL, BINARY(16) in MySQL. Storing the 36-character text form in a VARCHAR more than doubles the size, and that cost is repeated in every index and foreign key that references it.
Is a UUID secure enough to use as a secret token?
A v4 from a cryptographic source is unguessable, but unguessable is not the same as secret. Identifiers leak through referrer headers, logs, browser history and screenshots. Use real authorisation rather than relying on someone not knowing a URL.
What happened to UUID v1?
It embeds the generating machine's MAC address and a timestamp, which leaks information about your infrastructure and was the source of a well-known privacy incident in the 1990s. v7 gives you the time-ordering benefit without the hardware identifier, and has effectively replaced it.