About UUID Generator
UUID Generator emits cryptographically-random version 4 UUIDs (the standard random kind) and the newer version 7 UUIDs that embed a millisecond Unix timestamp at the start — perfect for primary keys you want naturally sortable by creation time. Generate one ID or up to 1000 in a single batch and export as plain text, JSON array, or CSV. Random bytes come from the browser's crypto.getRandomValues, which is a CSPRNG suitable for security tokens, session IDs and database keys. Nothing leaves the page.
- No uploads
- Browser-only
- Works offline
- 100% free
How it works
- 1
Choose v4 or v7
v4 is the classic fully-random UUID. v7 (RFC 9562) prepends a 48-bit Unix millisecond timestamp so the IDs sort by creation time — much better for database indexing.
- 2
Pick a count
Generate 1 to 1000 UUIDs in a single click. Re-roll the batch as many times as you want without leaving the page.
- 3
Export in your format
Copy as newline-separated text, a JSON array, or a single-column CSV — whichever your downstream tool expects.
What a UUID is for
A UUID (Universally Unique Identifier) is a 128-bit value, written as 32 hexadecimal digits in the familiar 8-4-4-4-12 grouping, whose entire purpose is to be unique without a central authority. That last part is the magic: two machines, on different networks, with no coordination, can each mint identifiers and rely on them not colliding. That is why UUIDs are the default primary key for distributed systems, event IDs, file names and offline-first apps that must generate keys before they ever reach a server. The format and every version are specified in RFC 9562, which in 2024 superseded the old RFC 4122.
v4 vs v1 vs v7 — which version to pick
Not all UUIDs are built the same way, and the version (the 13th hex digit) tells you how the bits were chosen. Version 4 is almost entirely random — 122 bits of randomness — which makes it the simplest and most private choice when you just need a unique opaque key. Version 1 encodes a timestamp plus the machine's network MAC address, which makes it sortable but can leak when and where it was generated. Version 7, new in RFC 9562, is the modern sweet spot: a millisecond Unix timestamp in the high bits followed by random bits, so the values are unique, unguessable enough, and sort in creation order.
| Version | Based on | Time-sortable | Best for |
|---|---|---|---|
| v4 | Random (122 bits) | No | General-purpose unique keys |
| v1 | Timestamp + MAC address | Yes | Legacy systems; leaks origin |
| v7 | Unix time + random | Yes | New database primary keys |
| v5 | SHA-1 of a name + namespace | No | Deterministic IDs from a name |
v7 is increasingly preferred for database keys because time-ordered values keep B-tree indexes compact, where scattered v4 keys fragment them.
Collision odds: why 'unique' holds up
The uniqueness of a v4 UUID is statistical, not guaranteed, but the numbers are reassuring. With 122 random bits, you would need to generate about 2.7 quintillion (2.7×10¹⁸) UUIDs before the probability of a single collision reached even one in a billion — that is the birthday-paradox maths applied to a 122-bit space. In practical terms, an application minting a thousand UUIDs per second for a hundred years has a vanishingly small chance of ever seeing a duplicate. You can safely treat v4 collisions as something that does not happen, which is the whole point of the format.
The realistic failure mode is not a cosmic collision but a broken generator — a weak random source, or a buggy library that truncates or reuses bits. Generate them with a vetted tool rather than rolling your own, and the statistical guarantee actually holds.
When a UUID must NOT be your secret
The most damaging UUID mistake is treating one as a password or capability token. A UUID is an identifier, not a secret. A v1 UUID is largely predictable from its timestamp and MAC; even a v4 is only as strong as the library that produced it, carries no expiry, and is routinely logged, embedded in URLs and shared freely precisely because it is meant to be public. Using a UUID as the only thing guarding a password-reset link or a private resource means anyone who can guess or find it gets in.
Use a UUID to name a thing and a purpose-built random token to guard it. When you need an unguessable bearer secret with real entropy, generate one with the secure token generator; keep the UUID for the identifier and let the token do the authentication. They look similar and serve opposite jobs.
Frequently asked questions about UUID Generator
When should I use v7 instead of v4?
Use v7 when your UUIDs become primary keys in a SQL database. Because v7 embeds the millisecond timestamp at the start, inserts append to the end of the index instead of fragmenting it — typically a 2–5x write speedup compared with random v4 keys. Use v4 when you specifically want IDs that leak no information about when they were created.
Are the v4 UUIDs cryptographically random?
Yes. They're generated from crypto.getRandomValues, the browser's CSPRNG, which on every modern OS is backed by the kernel entropy pool. The collision probability is the standard 1 in 2^122 — for context, you'd need to generate 1 billion UUIDs per second for ~85 years to have a 50% chance of a single collision.
Can I generate other UUID versions like v1 or v5?
v1 (MAC address + timestamp) leaks the machine's MAC and the exact creation time, so it's discouraged in modern systems. v5 (SHA-1 namespace) is occasionally useful for deterministic IDs derived from a name. Both are uncommon — if you have a real need, drop us a feature request and we'll add them.
Privacy, offline use, browser support, and pricing questions are answered on the site-wide FAQ.