How to Generate a UUID v4 in Your Browser

A UUID is a 128-bit identifier represented as 32 hexadecimal digits, usually grouped as 8-4-4-4-12. In current standards, RFC 9562 defines UUID versions 1 through 8 and supersedes RFC 4122.

For a browser tool that needs independent, opaque identifiers, UUID v4 is the straightforward choice. Its payload is random except for the version and variant bits. The important implementation rule is that those random bits must come from browser Web Crypto—not Math.random().

Generate a UUID v4 with Web Crypto

Modern browsers expose crypto.randomUUID(), which generates a UUID v4 using a cryptographically secure random-number generator. It is available only in a secure context such as HTTPS or localhost.

const id = crypto.randomUUID();
console.log(id); // for example: 2c5ea4c0-4067-4a9f-ae55-3f10c8d8f996

If randomUUID() is unavailable but Web Crypto exists, crypto.getRandomValues() can securely fill the 16 bytes before the version and variant bits are set. Math.random() is not a cryptographic random source and should not be used as a silent fallback.

The OpsecForge generator follows that rule: it uses crypto.randomUUID() when available, falls back only to crypto.getRandomValues(), and refuses to generate when secure browser randomness is unavailable.

UUID v4 Collision Probability

A standards-compliant UUID v4 has 122 random bits because the remaining bits identify its version and variant. That gives 2^122 possible random values—not 2^128 equally available UUID v4 values.

Collision risk depends on how many identifiers you generate. For n uniformly random UUID v4 values, the approximate probability of at least one collision while the probability is small is:

n² / (2 × 2^122)

At one billion generated UUIDs, that approximation is about 9.4 × 10^-20. This is extremely small, but it is not zero. Keep a unique constraint on database columns and handle a conflict by generating another value. RFC 9562 discusses both collision resistance and the difference between global and local uniqueness.

UUID v4, UUID v7, or an Integer?

Choose based on what the identifier must do:

• UUID v4: useful when independent systems need random identifiers without coordination and creation time should not be encoded.
• UUID v7: time ordered and often a better fit for database index locality, but its timestamp is visible.
• Sequential integer: compact and efficient inside one database, but predictable when exposed directly.

None of these choices replaces authorization. OWASP's IDOR guidance notes that complex identifiers are defense in depth; every request still needs a server-side permission check for the requested object.

Do Not Treat Every UUID as a Secret

UUIDs are identifiers. Even when a UUID v4 is generated with strong randomness, using it as a session credential requires more than unpredictability: secure transport and cookies, expiration, renewal, revocation, fixation defenses, safe storage, and server-side validation all matter.

For authenticated sessions, prefer your framework's established session mechanism and follow the OWASP Session Management Cheat Sheet. For cryptographic keys, use a purpose-built key-generation API. Do not paste a generated UUID into a system merely because a field asks for a “secret.”

Practical Checklist

• Generate browser UUID v4 values with crypto.randomUUID() or crypto.getRandomValues().
• Never downgrade to Math.random() while claiming cryptographic randomness.
• Keep database uniqueness constraints and retry the rare conflict.
• Use UUID v7 only when timestamp disclosure and time ordering fit the design.
• Enforce authorization independently of whether IDs are sequential or random.
• Use framework-managed session identifiers and dedicated cryptographic key generators for security credentials.

Sources

• RFC 9562: Universally Unique IDentifiers
• MDN: Crypto.randomUUID()
• MDN: Crypto.getRandomValues()
• OWASP: Session Management Cheat Sheet
• OWASP: Insecure Direct Object Reference Prevention