Which UUID version should I use — v4 or v7?
v4 is the default — purely random, no timestamp or ordering. v7 (RFC 9562) embeds a timestamp so UUIDs sort roughly chronologically, which helps database index locality when used as a primary key.
UUID Generator
Configuration
Generated UUIDs
Generated UUIDs will appear here.
Version reference
| Version | Basis | Sortable by creation time | Collision probability | Typical use |
|---|---|---|---|---|
| v1 | Timestamp (100ns ticks since 1582) + clock sequence + node ID | Roughly, within the same generator — timestamp bits aren't contiguous in the byte layout, so naive byte-sortability is worse than v7 | Extremely low in practice; theoretically guessable if timestamp and node ID are both known/narrow | Legacy systems that already standardized on v1; distributed IDs where rough recency matters more than a real random ID |
| v3 | MD5(namespace UUID + name) | No — deterministic, not time-based | Tied to MD5's collision resistance (weak in general, but a practical concern only if an attacker can choose the name input) | Deterministic IDs: same namespace+name must always produce the same UUID (e.g. mapping a URL or filename to a stable ID) |
| v4 | 122 bits of randomness | No — fully random | ~50% chance of any collision only after generating ~2.71 × 10¹⁸ UUIDs (billions of IDs/second for centuries) | The default general-purpose choice: session IDs, request IDs, anything that doesn't need to be sortable or deterministic |
| v5 | SHA-1(namespace UUID + name) | No — deterministic, not time-based | Same idea as v3 but with SHA-1 — the RFC-recommended choice over v3 when a name-based UUID is needed | Same use case as v3; prefer v5 over v3 for new systems since SHA-1 is a stronger hash than MD5 |
| v7 | Unix timestamp (ms, 48 bits) + 74 bits of randomness | Yes — the timestamp occupies the leading bytes, so lexicographic/byte sort order matches creation order | Still very low: 74 random bits per millisecond, effectively no realistic collision risk at normal generation rates | Database primary keys and anything indexed — sorts naturally, giving better index locality than v4 while staying essentially as collision-resistant |
Privacy note (v1): Classic RFC 4122 v1 embeds the generating machine's real MAC address in the node-ID field — a known privacy/fingerprinting concern. This tool does not do that: browsers have no access to hardware MAC addresses, so v1 here uses a random node ID with the multicast bit set, per RFC 4122 §4.5's explicit allowance for exactly this case.
About this UUID Generator
Generate random UUID v1, v4, and v7 values, or name-based v3/v5 UUIDs, securely in your browser.
UUIDs are generated locally using the Web Crypto API. Nothing is uploaded or stored.
FAQ
Is a UUID actually guaranteed to be unique?
Not mathematically guaranteed, but the collision odds are negligible — a v4 UUID has 122 random bits, so generating a billion per second for decades would still only give a 50% chance of one collision.
Can I use a UUID as a security token or access key?
No — a UUID is an identifier, not a secret. Treat it as a public identifier, not authentication credentials, unless it's part of a larger security design.
Does UUID v1 leak any information?
Yes — v1 embeds the generating machine's MAC address and a precise timestamp. Prefer v4 or v7 unless you specifically need v1's legacy format.
What are v3 and v5 for?
Deterministic, name-based UUIDs — the same namespace + name always produces the same UUID (v3 uses MD5, v5 uses SHA-1). Useful when you need a stable ID derived from an existing value, like a URL or filename, instead of a random one.
Is a generated UUID sent anywhere?
No — generated entirely in your browser.
Related tools
UUID Bulk GeneratorGenerate batches of up to 100 UUID v4 identifiers.Random String GeneratorGenerate secure random strings with custom character sets.Password GeneratorGenerate secure random passwords locally in your browser.Hash GeneratorHash text with MD5, SHA-1, SHA-256, SHA-384, and SHA-512 at once.