UUID generator
Generate UUIDs — v1 through v8 — and export in bulk.
Click Generate to create a UUID. Set Quantity up to 10,000 for bulk.
Validator & format converter
- Valid
- Version
- Variant
- Canonical
- No dashes
- Braces
- URN
About this tool
A UUID is a 128-bit identifier designed to be unique without coordination — useful for database primary keys, log correlation IDs, and file names that won't collide. The most common version is v4 (random), but v7 (timestamp-based and sortable) has become the modern pick for database IDs. This tool generates every RFC 4122 and RFC 9562 version — v1 through v8 — singly or in bulk up to 10,000 at a time. The v7 implementation is strictly monotonic, so even IDs generated in the same millisecond sort correctly — a detail most other generators get wrong.
How to use this tool
-
Pick a version
v4 is the safe default — random and collision-resistant. v7 if you need time-ordered IDs that sort naturally. v1/v3/v5 are RFC-compliant but rarely the right answer in 2026.
-
Generate
Click Generate for one UUID. Switch to Bulk mode to produce 10, 100, or 10,000 at once. Bulk runs entirely in your browser — even 10k is near-instant.
-
Copy or export
Tap the copy icon for a single value, or click Export CSV for bulk results. Format and Parse tools let you convert between hex, base64, and URN forms.
Frequently asked questions
Should I use v4 or v7?
For new database primary keys, prefer v7 — it's sortable by creation time, which keeps indexes efficient and makes logs easier to scan. Use v4 when you explicitly want random IDs with no time leakage (e.g. share tokens, session IDs).
What is a namespace UUID for (v3 and v5)?
v3 and v5 are deterministic: given the same namespace and name, they always produce the same UUID. Useful when you need a stable identifier for an external name (a URL, a DNS entry, a file path) without keeping a mapping table.
Are these UUIDs really unique?
For v4, the odds of a collision between two random UUIDs are vanishingly small — you'd need to generate billions before the probability becomes non-trivial. v1/v6/v7 embed timestamps so same-moment generation on the same machine is handled by the clock sequence and counter fields.
v4 vs v7 — which should I use?
v4 if you don't care about ordering. v7 if your IDs end up in a database index where sortable IDs avoid index hot-spots. v7 is newer (2024) — make sure your stack accepts it. Both are collision-safe for any realistic use.
Are UUIDs guaranteed unique?
Not guaranteed, but for v4 the probability of collision is so low it's not worth designing around. You'd need to generate roughly a billion UUIDs per second for 85 years to have a 50% chance of one duplicate.
Can I use UUIDs as primary keys?
Yes, but v4 hurts index locality in B-tree databases (Postgres, MySQL). Use v7 if you're picking a UUID specifically because you want a primary key — the time-ordered prefix keeps inserts clustered.
Troubleshooting
- Why are my v1 UUIDs identical across browser tabs?
v1 includes a MAC-address-derived node ID. Browsers don't expose your real MAC, so we substitute a per-session random node — but that node is stable within a tab. Open a fresh tab or refresh to rotate it.
- What does the namespace field do for v3/v5?
v3 and v5 are deterministic: same namespace + same name produce the same UUID every time. The namespace itself is a UUID; pick one of the RFC-defined namespaces (DNS, URL, OID, X.500) or generate your own v4 to use as a custom namespace.
- Is v7 actually time-ordered?
Yes — the first 48 bits are a Unix timestamp in milliseconds. UUIDs generated in order will sort in order. For values generated in the same millisecond, ordering is random (the remaining bits are entropy).