UUID v4 Generator
Generate one or 100,000 random v4 UUIDs in every notation a codebase demands — entirely on this device.
Do it offline:$ uuidgen
How to use it
- Set a count from 1 to 100,000. The page loads with one UUID already generated; changing the count updates the batch instantly. Above 10,000, generation moves to a background worker so the page stays responsive.
- Pick a format: lowercase (the canonical form, and the default), UPPERCASE, no hyphens, {braces}, or urn:uuid:. Changing the format never regenerates — it re-renders the same values in the new notation, which is the fastest way to see that all five are the same UUID.
- Press Regenerate — or ⌘↵ / Ctrl+Enter — to replace the whole batch with fresh values. Discarding random output is this tool's declared job, so there is no undo; your settings are never reset.
- Copy one value with its per-item button, copy the whole batch with Copy all, or download it as .txt (one per line), .csv (a single uuid column with a header row), or a .json array — always in the notation you selected.
- Share puts only your settings — count and format — into the link. The values themselves are never in the URL: they are random by definition, so a shared link would be a lie about reproducibility.
A fresh UUID is on screen before you touch anything, generated on this device by your browser's crypto.randomUUID — never fetched from a server. Ask for one or ask for 100,000: big batches run in a background worker so the page never freezes. Five notations — canonical lowercase, UPPERCASE, no hyphens, {braces}, and the urn:uuid: prefix — cover every convention a codebase demands. Nothing you generate leaves this device.
Examples
count = 1 · format = lowercase (canonical)9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6dA version 4 UUID. Hex digit 13 is always 4 (the version) and hex digit 17 is always 8, 9, a or b (the variant); the other 122 bits are random. Lowercase is the form RFC 9562 tells generators to emit.
format = UPPERCASE · no hyphens · {braces} · urn:uuid: — same UUID9B1DEB4D-3B7D-4BAD-9BDD-2B0D7B3DCB6D
9b1deb4d3b7d4bad9bdd2b0d7b3dcb6d
{9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d}
urn:uuid:9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6dOne UUID, four more notations — every line is the same 128-bit value. Case and punctuation are presentation, not identity: compare UUIDs case-insensitively and ignore the wrapping.
count = 3 · Download → .csvuuid
4356b76a-27fe-4a25-b667-2d066ca2c914
444a8377-492c-4c7c-9821-9b8faca6f8eb
1c2535a5-f364-45c2-9713-1b7b6f3decc6The CSV download is a single uuid column with a header row, emitted in whatever notation you selected. Outputs are random by design, so the build verifies these rows by shape — header, row count, version and variant bits — against the live engine rather than byte-for-byte.
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
Five notations, one identity
Switching this page's Format control never regenerates — it rewrites the same values, because the notation changes how a UUID is written, not which UUID it is. Uppercase, no-hyphens, braces and urn:uuid: are ways of writing a UUID, not different UUIDs. RFC 9562 tells generators to emit lowercase and consumers to accept either case on input, so the robust habit is: store the canonical lowercase hyphenated form, compare case-insensitively, and convert at the edge when a consumer insists — Windows registry keys want {braces}, some URN-based protocols want the urn:uuid: prefix, and column-width-obsessed schemas strip the hyphens. Two systems disagreeing about case is a formatting bug, never a different identifier.
What the 4 and the 8/9/a/b actually pin down
A UUID has 128 bits, but a v4 UUID only gets 122 of them from the random source. Four bits are the version field — the 4 you can see at hex digit 13 — and two bits are the variant field, which forces hex digit 17 to 8, 9, a or b. Those six fixed bits are how a parser can tell what kind of UUID it holds without any context. If a value fails that shape check, it is not a v4 UUID, no matter how random it looks.
Random keys and your database index
v4's greatest strength — no structure at all — is exactly what hurts B-tree indexes. Sequential keys append to the same index pages; random keys land everywhere, causing page splits, cache misses and write amplification at scale. If you are choosing a primary key for a high-insert table, that is the problem UUID v7 exists to solve: a millisecond timestamp in the high bits makes values sort by creation time while staying unique. Use v4 when unpredictability matters or ordering must not leak; reach for v7 when the index is the bottleneck.
100,000 UUIDs is about 3.6 MB of text
At 36 characters plus a newline each, the maximum batch is roughly 3.6 MB. The list you see is virtualized — the DOM only ever holds the rows near your viewport — and the download streams from memory, so the page stays interactive at the cap. The clipboard is the one weak link: some browsers refuse very large writes, so if Copy all fails on a huge batch, the tool offers the download instead of failing silently.
macOS uuidgen prints uppercase
The CLI line on this page is honest but platform-flavored: uuidgen on macOS prints UPPERCASE, most Linux builds print lowercase, and PowerShell's [guid]::NewGuid() prints lowercase without braces. All of them are valid v4 UUIDs. If a diff between two environments shows UUIDs differing only in case, you are looking at the tools' output conventions, not at different values.
Where the randomness comes from
crypto.randomUUID is specified to produce version 4 UUIDs from a cryptographically strong random source — in practice, your operating system's CSPRNG. It is available only in secure contexts, which this site always is. That pedigree matters: UUID collisions observed in the wild almost always trace back to generators seeded with timestamps or Math.random, not to bad luck with 122 honest bits.
A UUID is not a credential
A v4 UUID from a CSPRNG carries 122 bits of entropy — more than enough to be unguessable. The problem is everything else: identifiers get logged, indexed, sent in URLs, and shown in support tickets, because that is what identifiers are for. Treat a UUID as a name, not a secret. If you need a bearer token, generate one designed for the job and keep it out of places names go.
Common errors
100,000 is the browser-side cap — need more? script it: `python -c "import uuid; print(uuid.uuid4())"` or use the API-shaped V2- The cap keeps the page honest: 100,000 values is about 3.6 MB of text, near the practical limit a browser tab can render, copy and download without degrading. Past that, a script is genuinely the better tool — wrap the one-liner in a loop, or call uuid.uuid4() directly in your own code. Your settings are untouched; nothing is truncated silently.
Count must be a whole number between 1 and 100,000.- The count field itself will not let you type this — the error exists because restored links and hand-edited URLs are validated like any other untrusted input. A fractional, negative or non-numeric count is refused with your settings left as they were.
Secure random generation is unavailable in this context.- crypto.randomUUID exists only in secure contexts. This site is HTTPS-only, so you should never see this here; it can appear if the page is re-served over plain http:// — an intranet mirror, a misconfigured proxy. There is no insecure fallback by design: the tool refuses rather than quietly downgrade to weaker randomness.
FAQ
What is the difference between UUID v4 and v7?
v4 is 122 random bits with no internal structure; v7 leads with a 48-bit Unix millisecond timestamp and fills the rest with randomness. Both are defined by RFC 9562 and look identical at a glance — only the version digit differs. The practical difference is ordering: v7 values sort by creation time, which keeps database indexes compact under heavy inserts, but they also reveal when a row was created. Pick v4 when unpredictability matters or timestamps must not leak; pick v7 when the identifier is a primary key and insert performance matters.
Are UUIDs actually unique?
Not guaranteed — overwhelmingly probable. A v4 UUID has 122 random bits, about 5.3 × 10³⁶ possible values. By the birthday math, you would need to generate a billion UUIDs per second for roughly 86 years to reach a 50% chance of a single collision; after 103 trillion UUIDs the chance of any collision is still about one in a billion. A 100,000 batch from this page carries a duplicate risk on the order of 10⁻²⁷. Real-world collisions come from broken or badly seeded generators and from copy-pasted fixtures — not from chance.
Should I store UUIDs as text or binary?
A UUID is 16 bytes of data; the familiar 36-character string is a display format that costs more than twice that, in the row and again in every index. Prefer your database's native type — uuid in Postgres, UNIQUEIDENTIFIER in SQL Server, BINARY(16) in MySQL — and render the hyphenated form at the edges. Note that stripping hyphens only shrinks the text to 32 characters: it is still text. The real saving is the native 16-byte representation, plus the type safety of a column that rejects non-UUIDs.
Are the uppercase and no-hyphen forms still valid UUIDs?
Yes — they are the same UUID written differently. Hexadecimal is case-insensitive, and the hyphens sit at fixed positions (8-4-4-4-12), so both carry zero information. RFC 9562 asks generators to emit lowercase but consumers to accept either case. The braces form is Microsoft's GUID registry convention and urn:uuid: is the formal URN notation — parse all of them back to the same canonical lowercase value before comparing.
Is it safe to generate UUIDs online?
On this page, yes, and you can verify the claim rather than trust it: generation runs entirely in your browser via crypto.randomUUID, which draws from your operating system's cryptographic random source. After the page loads, no network request carries anything you generate — watch the network tab while you regenerate. That is the honest answer to a fair worry: with a server-side generator you cannot audit what is logged; here there is nothing to audit.
Is a GUID different from a UUID?
No — GUID is Microsoft's name for the same 128-bit identifier. .NET's Guid.NewGuid() produces standard v4 values, and SQL Server's UNIQUEIDENTIFIER stores them like any other UUID. The visible differences are conventions: Windows tooling often prints GUIDs in uppercase and wraps them in braces, which is exactly the {braces} format this page offers. You can exchange UUIDs and GUIDs freely as long as you compare them case-insensitively.
How many UUIDs can I generate at once?
100,000 — the browser-side cap. Batches up to 10,000 generate instantly on the page; larger ones run in a background worker and render through a virtualized list, since the full batch is about 3.6 MB of text. Beyond the cap, a script is the better tool and the refusal message says so: python -c "import uuid; print(uuid.uuid4())" emits one UUID per run — put it in a loop, or use your language's UUID library directly.
Keyboard shortcuts
- ⌘/Ctrl + Enter
- Regenerate — replace the whole batch with fresh UUIDs.
- ⌘/Ctrl + S
- Download the batch as .txt (on this page it downloads instead of saving the page).
- ⌘/Ctrl + C
- Copy all UUIDs when nothing is selected and focus is in the tool. A text selection — including in the count field — still copies normally.
- ⌘/Ctrl + Shift + C
- Copy all UUIDs even while a selection is active.
- t
- Cycle the color theme (outside text fields; single-key shortcuts can be disabled).
- ? or ⌘/Ctrl + /
- Open the shortcut help overlay in the tool.
- Esc
- Close an open dialog.