A UUID generator with v4 and v7 in one place.
Generate v4 (random) and v7 (time-ordered) UUIDs in bulk, formatted to match the column type or convention you target. Powered by the Web Crypto API; no input, no output, nothing leaves the page.
Every UUID is generated in this browser tab using `crypto.getRandomValues` for the random bits and `Date.now()` for the v7 timestamp. The page makes no network calls. We never see anything you generate, and nothing is logged.
Two versions, four formats, and the bulk mode you need.
A generator that uses the right primitive (`crypto.getRandomValues`, not `Math.random`), supports both v4 and v7 with full RFC compliance, and lets you tune the output format to whatever your column or convention demands.
The default for most cases. 122 bits of entropy means collision probability stays vanishingly small even at internet scale. Backed by `crypto.randomUUID` where available, with a hand-rolled fallback that uses the same CSPRNG.
A 48-bit Unix-millisecond timestamp prefix followed by 74 bits of randomness. Sortable like a sequential ID, unguessable like a random one — the modern default for primary keys (PostgreSQL, MySQL 8, etc.). Conforms to RFC 9562.
All entropy comes from `crypto.getRandomValues`, the same CSPRNG the browser uses for TLS. `Math.random`-backed generators (still surprisingly common in npm) are predictable from a few outputs and not safe for security-sensitive use.
Standard 8-4-4-4-12, no hyphens (compact form for `CHAR(32)` columns or URL slugs), wrapped in `{braces}` (Microsoft GUID style), and UPPERCASE. Switch on the fly without regenerating.
Generate 1, 10, 50, or 100 at a time. Useful for seeding tables, scripting fixtures, or stress-testing a system that hashes IDs.
Click any UUID to copy that one. The Copy all button copies the full list newline-separated — paste straight into a SQL `IN (…)` clause or a fixture file.
Switching version, format, or bulk count regenerates instantly. No spinner, no confirmation — pick the shape, get the IDs.
Use anonymously. No account, no history, no telemetry. Inspect the network tab and watch nothing happen.
For every place a unique ID has to land.
For deterministic test fixtures or migration scripts that need to reference a row before it exists. v7 gives you sortable IDs that interleave naturally with sequence-based ones.
Stripe, square, and most payment APIs require an `Idempotency-Key` header on POST requests. A v4 UUID is the canonical choice — generate one per request, retry safely on network failure.
Distributed tracing requires unique IDs per request span. v4 is fine, v7 is better when you want to bucket traces by time without needing the timestamp separately.
When a user uploads a file, name the object after a fresh UUID rather than the original filename — avoids collisions and keeps user input out of your bucket key.
128 bits of entropy is overkill for a token an attacker has minutes to guess — but the cost is zero, and using a UUID keeps the token a fixed shape. Encode in URL-safe Base64 if length matters.
Unguessable share links want random IDs (v4), not sequential integers — sequential exposes how many docs you have and lets curious users walk neighbor IDs.
UUIDs, the plain answers.
Use v7 when the UUID is a database primary key. v7 IDs sort by creation time, which means new rows append to the end of the B-tree index instead of scattering across it — fewer page splits, smaller indexes, faster inserts at scale. v4 is fine for everything else (request IDs, file names, share links) where ordering does not matter.
v1 encodes the generating machine's MAC address into the ID. In a browser there is no MAC to read, so any v1 implementation has to fake the node ID — at which point the version is misleading. The modern recommendation (per the RFC 9562 update) is to use v7 when you want time-ordering, and v4 when you do not. We follow that.
Two reasons: opacity and distributedness. Auto-increment leaks how many rows exist (any user can walk neighbor IDs); v7 hides everything but the rough creation timestamp. And v7 can be generated client-side or by any service in the system without coordinating with a central sequence — every node mints its own ID, no contention.
For v4 with 122 random bits: about 50% probability of any collision after generating 2.71 × 10^18 IDs. At 1 million IDs/second, that is roughly 86,000 years. v7 has fewer random bits (74) but adds a millisecond timestamp, so collision requires generating two IDs in the same millisecond AND those two having identical 74-bit random tails — also vanishingly unlikely.
No. Generation runs entirely in this browser tab, using `crypto.randomUUID` and `crypto.getRandomValues`. The page makes no network calls. Open DevTools → Network and watch nothing happen.
Yes — every browser shipped since mid-2022 supports it (Chrome 92+, Firefox 95+, Safari 15.4+). For v7 (newer, no native API yet), we hand-roll the construction using `crypto.getRandomValues` for the random tail and `Date.now()` for the timestamp prefix, with the version and variant bits set per RFC 9562.
Storing all those IDs in a real database?
Sign up for the free tier and you get $100 in credits, plus VMs, managed PostgreSQL with native UUID support, object storage, and zero-config autoscaling across four regions.