UUID Generator
Generate cryptographically random UUID v4 and time-sortable UUID v7 in bulk, then copy them as a list, JSON array or SQL insert.
UUID v4
0 generatedGenerating…
Generated locally with your browser's cryptographic random number generator. Values are never sent to a server, logged, or reused.
About the UUID Generator
A UUID (Universally Unique Identifier) is a 128-bit value that any machine can generate on its own — no coordination with a central database, no reserved block of IDs, no risk of two services handing out the same number. That property is what makes UUIDs the default primary key and correlation ID in distributed systems, and it is what this UUID generator produces: cryptographically random identifiers, computed entirely in your browser, in the two versions that matter for application development.
RFC 9562 (which obsoleted the older RFC 4122 in 2024) formally defines eight UUID versions, but only two are relevant here. Version 4 is 122 bits of pure randomness — 6 of the 128 bits are fixed to mark the version and variant, and the rest carry no information at all. It is unordered, unpredictable, and has been the default choice for two decades. Version 7 keeps that same unpredictability in its lower bits but replaces the top 48 bits with a Unix millisecond timestamp, so v7 values sort chronologically as plain strings — the newest UUID is always the lexicographically largest one.
That sortability is not a cosmetic feature. A v4 primary key scatters every insert to a random position in a database's B-tree index, forcing random page writes and hurting cache locality as a table grows. A v7 key appends to the right edge of the index the way an auto-incrementing integer does, while still letting any node generate IDs offline with no round trip to the database. It is why Postgres, MySQL and most major ORMs added native v7 support once the RFC stabilized, and why 'uuid v7' has become one of the fastest-growing searches in the UUID family — developers migrating existing v4 schemas specifically to fix index bloat.
Both versions here are generated with the browser's Web Crypto API — crypto.randomUUID() where available, falling back to crypto.getRandomValues() — never Math.random(), which is not cryptographically secure and must not back an identifier that will ever be used as a token, a session key, or anything else where guessability matters.
- UUID v4 (random) and RFC 9562 UUID v7 (time-ordered), generated with crypto.getRandomValues — never Math.random
- Bulk generation, from a single UUID up to 500 in one batch
- Five output formats: plain list, JSON array, quoted comma-separated list, CSV, and a ready-to-run SQL INSERT statement
- Optional uppercase output, for the rare system that expects it
- For v7, the embedded millisecond creation timestamp is decoded and shown next to the batch
- Regenerate button for a fresh batch without changing any other setting
- Nothing leaves your browser — no network request is made to generate or format any UUID
How to use it
- Choose v4 for a purely random identifier with no embedded information, or v7 if the values will be a database key and you want them to sort by creation time.
- Pick how many you need — from 1 up to 500 per batch.
- Choose an output format. SQL INSERT and JSON array save a reformatting step when seeding data or writing a fixture.
- Toggle Uppercase if your target system expects it — most don't; UUIDs are case-insensitive by spec.
- Press Regenerate for a fresh batch, then copy the whole block with the Copy button.
Real-world use cases
Backend & database engineers
Generate a batch of v7 UUIDs for a new table's primary key when index locality matters, or grab a SQL INSERT block pre-formatted for a seed script without hand-writing the syntax.
Frontend & full-stack developers
Pull a quick v4 identifier for a React key, a temporary DOM id, or a mock object in a component you're prototyping, without spinning up a terminal for one value.
QA & test engineers
Generate a batch of distinct IDs as JSON or CSV to seed fixtures and test data, where the values only need to be unique and well-formed, not meaningful.
DevOps & platform engineers
Produce a correlation ID or request ID for a config file, a curl test, or a support ticket reproduction step — a v4 UUID pasted straight into a header or log line.
Engineers migrating a schema from v4 to v7
Compare the two formats side by side, confirm the version nibble and decoded timestamp of a v7 sample, and generate representative values for a migration script or a teammate's PR review before touching production data.
Examples
UUID v4
version: v4
7c9e6679-7425-40de-944b-e07fc1f90ae7
The 13th hex digit is the version — 4 here. The 17th encodes the variant and is always 8, 9, a or b. Every other digit is random and carries no meaning.
UUID v7, sorted as text
version: v7, count: 3
0198e3c1-9a40-7c31-8f2a-1d4b6e0c9a11 0198e3c1-9a41-7be2-9c05-77f0a1c3d4e8 0198e3c1-9a41-7d19-b0aa-52c9e8b73f60
The shared prefix is the millisecond timestamp — the last two here were generated one millisecond after the first. Sorting these strings sorts them by creation time, so a plain ORDER BY id becomes a chronological ordering with no separate created_at needed for ordering alone.
Seeding a table
format: SQL INSERT, count: 2
INSERT INTO items (id) VALUES
('018f2b9c-31a4-7c6e-9d2f-0a1b2c3d4e5f'),
('018f2b9c-31a4-7f01-8e3a-9b8c7d6e5f40');Handy for seed scripts and fixtures where you need stable, well-formed identifiers checked into the repository rather than generated at insert time.
Decoding a v7 timestamp
0198e3c1-9a40-7c31-8f2a-1d4b6e0c9a11
Encodes 2025-08-26T00:22:52.736Z
The first 12 hex digits (48 bits) are a big-endian Unix millisecond count. This tool decodes it back to a date next to the batch — useful for confirming a v7 value really was generated when you think it was, or for spotting a clock that's wrong.
Common errors
| Message | Cause | Fix |
|---|---|---|
| Fragmented index / slow inserts on a UUID primary key | Random v4 values are written to arbitrary positions in a clustered B-tree index, so every insert dirties a different page and defeats the database's write cache. | Switch new tables to v7 (or ULID). Sequential prefixes keep inserts at the right edge of the index, close to how an auto-incrementing integer behaves. |
| invalid input syntax for type uuid | Postgres received a string with the wrong length, stray whitespace, or surrounding braces left over from a .NET Guid.ToString("B") call, e.g. {7c9e6679-...}. | Trim it to the canonical 36-character hyphenated form with no braces. Postgres accepts the value case-insensitively but rejects extra characters. |
| Duplicate key violation on a UUID column | Almost always a bug that reuses one generated value — hoisted out of a loop, cached in a shared object, or copy-pasted as a placeholder — not an actual v4 collision. | Check that the identifier is generated fresh per row or per request. See the FAQ below on collision odds: a genuine v4 collision is not a realistic explanation. |
| crypto.randomUUID is not a function | An insecure context. The Web Crypto API's randomUUID() and getRandomValues() are only exposed on HTTPS and localhost, not on plain HTTP. | Serve the page over HTTPS, or use localhost during development. This tool itself is served over HTTPS, so it always has access to it. |
| A v7 UUID sorts before one generated earlier | Clock skew between the machines generating them, or two values generated in the same millisecond where the random suffix happened to sort the earlier one higher. | v7 guarantees millisecond-resolution ordering across a synchronized clock, not sub-millisecond ordering. If you need a strict generation order within the same millisecond, that guarantee does not exist for v7 — or for any UUID version. |
| A UUID column rejects a value that looks correct | The variant nibble (the first character of the third group) is not 8, 9, a or b, which means the string is not a valid RFC 9562 UUID even though it has the right length and hyphen positions. | Check where the value actually came from — a hand-typed placeholder or a non-UUID GUID variant will fail this check even when it superficially looks right. |
Frequently asked questions
›What is the difference between UUID v4 and v7?
v4 is 122 bits of randomness with no structure at all. v7 replaces the first 48 bits with a Unix millisecond timestamp, keeping 74 random bits. v7 values therefore sort by creation time and perform far better as database primary keys, at the cost of revealing roughly when each record was created — which matters if the ID itself is ever exposed to a user.
›Which version should I use for a database primary key?
v7, in nearly all new schemas. It keeps the decentralized generation that makes UUIDs useful in the first place, while restoring the index locality of an auto-incrementing integer. Reach for v4 only when leaking approximate creation time is genuinely unacceptable — a case less common than it first sounds, since created_at columns usually reveal the same information anyway.
›Can two UUIDs ever collide?
In practice, no. With 122 random bits, the birthday bound puts 50% collision odds at around 2.3 × 10^18 generated v4 UUIDs — a billion every single second for roughly 73 years. A duplicate showing up in real data is a code bug (an ID reused, hardcoded, or hoisted out of a loop), not bad luck.
›Are these random enough to use as security tokens?
The randomness comes from crypto.getRandomValues, the same CSPRNG the browser uses for TLS, so a v4 UUID is genuinely unpredictable. Even so, prefer a purpose-built token of at least 256 bits for session IDs or password-reset tokens — UUIDs are identifiers first, and they're routinely logged, embedded in URLs, and included in error reports and analytics events in ways a dedicated secret token would not be.
›Are the generated UUIDs stored or logged anywhere?
No. Generation happens entirely in your browser using the Web Crypto API, and nothing is transmitted to a server. Reloading the page produces an entirely new batch with no memory of the previous one.
›How is UUID v7 different from ULID?
They solve the same problem — a sortable, decentralized identifier — and both encode a 48-bit millisecond timestamp. ULID represents that as a 26-character Crockford base32 string with its own text format, while v7 is a standard RFC 9562 UUID and drops straight into any existing uuid database column, ORM field, or library expecting a UUID, with no schema change required.
›What do the version and variant digits mean, and can I identify a version by looking at the string?
Yes. In the canonical 8-4-4-4-12 hex layout, the first character of the third group is always the version — 4 for v4, 7 for v7 — and the first character of the fourth group (the variant) is always 8, 9, a or b for any RFC 9562 UUID. That's how this tool decodes a v7 timestamp on sight: it checks that digit before reading the preceding 12 hex characters as milliseconds.
›Is a GUID the same thing as a UUID?
For almost every practical purpose, yes — GUID is Microsoft's name for the same 128-bit layout defined by RFC 9562. The .NET Guid type historically defaulted to a different byte-ordering convention in its ToString("B")-style braced format and used version 4 by default, but a Guid and a UUID produced by this tool are interchangeable once normalized to the standard 36-character hyphenated string.
›Why does the count only go up to 500?
It's a UX limit, not a cryptographic one — generating 500 UUIDs client-side takes a few milliseconds regardless of version. For seeding thousands of rows, generate in a script instead; this tool is built for the common case of a handful to a few hundred values for a fixture, a migration test, or a one-off insert.
Last updated