Developer Tools

UUID Security and Privacy: Are Generated UUIDs Truly Random?

Learn about UUID generation security, privacy implications of different versions, and whether UUIDs are safe for security-sensitive applications like session tokens.

By Inventive HQ Team

Are generated UUIDs truly random? A UUIDv4 is truly random — 122 of its 128 bits come from a random source, giving about 5.3 x 10^36 possible values — but only if it was generated by a cryptographically secure RNG such as crypto.randomUUID(). A UUID built on JavaScript's Math.random() is predictable, and other versions leak real data: v1 and v6 embed the machine's MAC address and a timestamp, and v7 embeds a creation timestamp. So "UUID" is not one security property — it is at least six, ranging from cryptographically strong to actively identifying.

That is the summary an AI Overview will give you. Here is what it can't show you: which specific versions leak what, how a real virus author got caught by his own UUID, and a live generator you can inspect byte by byte. Generate a few UUIDs below and watch which fields stay constant across them — those constant bytes are exactly the metadata that can identify you.

Open the Uuid Generator toolFree, in your browser on inventivehq.com →
Loading interactive tool...

The six UUID versions, ranked by security and privacy

The UUID format is defined by RFC 9562 (published May 2024, replacing the older RFC 4122). All versions are 128 bits, formatted as xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M marks the version and N marks the variant. What differs is where the other 122 bits come from — and that difference is the entire security and privacy story.

VersionHow it's builtRandom bitsLeaksGuessable?Use it for
v148-bit MAC + 60-bit timestamp + clock seq~14MAC address + creation timePartly (time is sequential)Legacy systems only; avoid
v3MD5 hash of namespace + name0The input, if input space is smallYes, if input is knownDeterministic IDs, never secrets
v4Random122NothingNo (with a CSPRNG)General IDs, tokens, keys
v5SHA-1 hash of namespace + name0The input, if input space is smallYes, if input is knownDeterministic IDs, never secrets
v6Reordered v1 (time-sortable)~14MAC address + creation timePartlyTime-sortable legacy migration
v748-bit Unix ms timestamp + random74Creation timestampNo (random tail), but time is visibleDB primary keys, sortable IDs
Which should I use?————v4 for anonymous random IDs; v7 for sortable DB keys; never v1/v6 for anything sensitive

The takeaway: v4 and v7 are the only versions with enough randomness to resist guessing. v3 and v5 are hashes with zero randomness — same input always yields the same UUID, so they are useful for deduplication but must never be treated as secret. v1 and v6 carry a MAC address and timestamp in the clear.

Anatomy of a UUIDv4: which bytes are random, which are fixed

A common misconception is that all 128 bits of a v4 UUID are random. Six of them are not: four bits are pinned to the version (4) and two bits are pinned to the variant (10). Those fixed bits are why every v4 UUID has a 4 at the start of the third group and one of 8, 9, a, or b at the start of the fourth.

Anatomy of a UUIDv4 showing 122 random bits and 6 fixed bits A UUIDv4 layout: the version nibble is fixed to 4, the variant bits are fixed to 8-b, and the remaining 122 bits are random with 5.3 x 10 to the 36 possible values. UUIDv4: 128 bits = 122 random + 6 fixed 3f9a7c1e-b204-4e8d-a1f2-6b3c9d0e5a71 Version nibble fixed to "4" (4 bits) Variant bits fixed to 8/9/a/b (2 bits) 122 random bits 5.3 x 10^36 values

Those 122 random bits are what make a v4 UUID unguessable — but only when they are drawn from a cryptographically secure source. That single dependency is where most real-world UUID vulnerabilities live.

The one thing that actually breaks UUID security: the RNG

The version tells you how many bits are supposed to be random. Whether they are random depends entirely on the underlying random number generator. This is the failure mode that turns a "secure" v4 into a predictable token.

  • Math.random() is not cryptographic. In V8, Node, and every browser, Math.random() is a fast pseudo-random generator (xorshift128+) seeded from a small state. Given a handful of outputs, researchers have reconstructed its internal state and predicted every subsequent value. A UUIDv4 assembled from Math.random() bytes inherits that predictability — the 122 "random" bits are an illusion.
  • Use the platform CSPRNG. In modern environments call crypto.randomUUID() (Node 16.7+, all current browsers, Deno, Bun). It draws from the OS cryptographically secure RNG and returns a compliant v4 in one line. For raw bytes, use crypto.getRandomValues() (browser) or crypto.randomBytes() (Node).
  • Old libraries and forks are the risk. Some legacy uuid polyfills, homegrown implementations, and copied Stack Overflow snippets fall back to Math.random() when no crypto API is found. That fallback is silent — the UUID still looks perfectly formatted.

If you generate a UUID and hand it out as a password-reset link, an unguessable value is the whole point. A predictable RNG quietly removes that guarantee while leaving the output looking identical.

Advertisement

The privacy leak: how a UUID caught a virus author

In 1999 the Melissa macro virus spread through infected Word documents. Microsoft Office at the time embedded a UUIDv1-style GUID in document metadata — and UUIDv1 encodes the network card's MAC address directly in its final 48 bits. Investigators extracted the MAC address from documents linked to the virus, matched it to hardware, and identified the author. His own identifier convicted him.

That is the concrete privacy cost of a time-and-MAC UUID. The lesson generalizes:

What each UUID version reveals about its origin UUIDv1 and v6 leak MAC address and timestamp, v7 leaks a timestamp, v4 leaks nothing. What a single UUID reveals about where it came from v1 / v6 MAC address creation time deanonymizes v7 creation time (48-bit ms) orderable v3 / v5 the hashed input (if guessable) deterministic v4 nothing 122 random bits anonymous

If a UUID will ever appear in a document, a URL, a public API response, or a data export, prefer v4 (leaks nothing) or, where sortability matters, v7 (leaks only a timestamp). Reserve v1 and v6 for internal systems that specifically need the node/time fields and where the MAC-address exposure is understood and acceptable.

Identifier versus secret: the distinction that trips teams up

The single most common UUID mistake is conflating two different jobs:

  • An identifier must be unique. It is not required to be secret, and in practice it is not — UUIDs show up in URLs, logs, referrer headers, error messages, and analytics. Any version satisfies "unique."
  • A secret must be unguessable and confidential. Only a v4 (or v7) from a CSPRNG is unguessable, and confidentiality is your job: don't log it, don't leak it via Referer, expire it.

Problems appear when a team uses a UUID as a capability — "if you know the URL, you're authorized" — without checking which version it is. A predictable v1 or a deterministic v5 used as a password-reset token is a real vulnerability, because the value can be reconstructed rather than guessed. A v4 from crypto.randomUUID() can safely double as a secret, provided you also treat it like one: short expiry, single use, never written to logs. For genuinely long-lived secrets, a dedicated 256-bit random token is cleaner than borrowing a UUID for the role.

Practical recommendations

  1. Default to v4 for anonymous identifiers and any value that might be exposed. It leaks nothing and is unguessable with a proper RNG.
  2. Use v7 for database primary keys when you want time-sortable, index-friendly IDs — but remember the embedded timestamp is readable by anyone who holds the ID.
  3. Never assemble UUIDs from Math.random(). Call crypto.randomUUID() or crypto.getRandomValues(). Audit old dependencies for silent Math.random() fallbacks.
  4. Avoid v1 and v6 in anything user-facing; they broadcast a MAC address and creation time.
  5. Treat v3/v5 as public. They are deterministic hashes — useful for dedup, useless as secrets.
  6. If a UUID grants access, treat it as a secret: CSPRNG source, expiry, single use, and keep it out of logs and referrer headers.

Generate and inspect a few versions with the tool above, or read our v1 / v4 / v5 version comparison for a deeper field-by-field breakdown. All generation in our tool happens client-side via the browser's native crypto API, so no value is ever transmitted to a server.

Frequently Asked Questions

Are UUIDs cryptographically secure?

Only if two conditions hold. First, the version must carry real randomness: UUIDv4 has 122 random bits and UUIDv7 has 74, while v1, v3, v5 and v6 are partly or fully predictable. Second, those random bits must come from a cryptographically secure RNG such as crypto.randomUUID() or crypto.getRandomValues() — not JavaScript's Math.random(), which is predictable and makes any UUID built on it guessable.

Can a UUIDv4 be guessed or brute-forced?

A properly generated UUIDv4 has 122 bits of entropy, roughly 5.3 x 10^36 possible values. Brute-forcing that space is infeasible. The realistic attack is not brute force but a weak RNG: if the UUID was generated with Math.random() or a seeded/predictable generator, an attacker can reconstruct the internal state and predict future IDs without guessing the full space.

Do UUIDs leak private information?

Some versions do. UUIDv1 and UUIDv6 embed the generating machine's MAC address and a creation timestamp, which can deanonymize a user or trace a document back to a device. UUIDv7 embeds a millisecond creation timestamp (no MAC). UUIDv4 embeds nothing meaningful — it is 122 random bits. This is exactly how the author of the 1999 Melissa virus was traced, via the MAC address baked into a Word document's GUID.

Is it safe to use a UUID as a session token or password reset link?

Only a UUIDv4 (or v7) generated by a CSPRNG is safe enough, and even then you must treat it as a secret — never log it, never expose it in a referrer header, and always give it an expiry. Never use v1, v3, v5 or v6 for anything that grants access, because they are predictable or deterministic. For long-lived secrets, a dedicated 256-bit random token is a cleaner choice than a UUID.

What is the difference between a UUID and a secret token?

A UUID is an identifier: it is meant to be unique, not hidden, and it routinely appears in URLs, logs, and API responses. A secret token is meant to be unguessable and confidential. A UUIDv4 happens to be unguessable, so it can double as a secret, but the moment you treat any UUID as automatically confidential you risk exposing predictable v1/v3/v5 IDs as if they were passwords.

Which UUID version should I use in 2026?

Use UUIDv4 when you want a pure random identifier with no metadata leak. Use UUIDv7 when you also want database-friendly, time-sortable keys and can accept a visible creation timestamp. Avoid v1 and v6 unless you specifically need node/time fields and understand the MAC-address leak. Use v3/v5 only for deterministic, content-derived IDs that never need to be secret.

Does UUIDv7 have privacy problems?

UUIDv7 removes the MAC-address leak of v1 but still embeds a 48-bit millisecond creation timestamp in its leading bits. That means anyone holding a v7 can read when the record was created and can order records chronologically. For most database primary keys that is fine; for records whose creation time is sensitive (medical, HR, moderation), it is a real information leak to consider.

Are online UUID generators safe to use?

A client-side generator that runs entirely in your browser and calls the native crypto.randomUUID() API never transmits the value anywhere, so it is safe. Avoid server-side generators that return UUIDs over the network for anything security-sensitive — the operator sees every value they hand you, which defeats the purpose of a secret token.

uuid-generator

Free tools you can use right now

Related articles

Referral link · we earn a reward
Incogni
Get your personal data deleted from data brokers.

Sends removal requests to data brokers and people-search sites on your behalf, then keeps re-sending them as your details reappear. Our link takes 58% off annual plans.

Take a look