How likely is a UUID collision?

Vanishingly unlikely. A version-4 UUID carries 122 random bits, so you would need to generate on the order of a billion UUIDs per second for decades before a collision became a realistic concern. For ordinary application use you can treat them as unique.

Can I use a UUID as a security token?

It is better not to. A v4 UUID is unpredictable, but it is designed as an identifier — it is often logged, put in URLs, and shared between systems, and it has no expiry or revocation. Use a purpose-built token or session mechanism for anything that grants access.

UUID Generator

Generates a random version-4 UUID (universally unique identifier), suitable for database keys, test fixtures, or unique reference IDs. Generated locally in your browser using the Web Crypto API. It is never sent to a server, never logged, and never included in analytics.

Generated entirely in your browser using the Web Crypto API. Nothing you generate here is ever sent to a server, logged, or included in analytics.

Your result will appear here.

What this generator does

Produces version 4 UUIDs — the 128-bit random identifiers used as database primary keys, request correlation IDs, idempotency keys and file names. Each one is generated in your browser from cryptographic randomness, so it is suitable for real use rather than only for examples.

How to use this tool

Press generate to create a new UUID.
Copy it with one tap.

Worked examples

A seed row in a test fixture: 3f2504e0-4f89-41d3-9a0c-0305e82c3301 — the 13th character is always 4, marking the version, and the 17th is one of 8, 9, a or b, marking the variant.
A correlation ID for tracing a request: Generate one per request and log it at every hop. Collisions are implausible enough that you can treat the ID as unique without coordinating between services.

Common use cases

Generating a unique ID for testing or development
Creating placeholder database keys
Any use case needing a unique random identifier

How this generator works

Sixteen random bytes are read from your browser's Web Crypto random generator. Six of those bits are then overwritten to mark the value as version 4 with the RFC 4122 variant — that is why the 13th hex character is always 4 and the 17th is always 8, 9, a or b. The remaining 122 bits stay random, and the bytes are formatted as the familiar 8-4-4-4-12 hex string. No counter, timestamp, MAC address or server round trip is involved, so identical code on two machines produces unrelated values.

Randomness and fairness

The random bits come from your browser's cryptographic random number generator, with the version and variant bits set as RFC 4122 requires. A version 4 UUID has 122 random bits, which is why collisions are treated as negligible in practice rather than actively prevented: you would need to generate billions of them before a repeat became likely. This tool does not check generated values against each other, because at that scale there is nothing useful to check.

For how randomness is produced across the whole site, see how Generate Random works.

Limitations and good to know

A v4 UUID is random, not secret. It is fine as an identifier but should never be used as an access token, session key or password — anything that grants access needs a value designed to be unguessable and revocable.
Random UUIDs make poor clustered primary keys in some databases, because inserts land at random points in the index rather than appending. Where that matters, a time-ordered scheme such as UUIDv7 or ULID is usually the better choice.
Uniqueness is probabilistic rather than guaranteed. With 122 random bits a collision is not worth designing around, but it is not the same as a database sequence that cannot collide by construction.
This generates v4 only. Versions 1, 5 and 7 have different structures and are not produced here.

Common mistakes

Using a UUID as a security token: A version 4 UUID is unguessable enough to be a fine identifier, but it is a widely recognised format with a predictable shape, and it is often logged, cached and shared casually. Use the API key or token generators for anything that grants access.
Expecting UUIDs to sort chronologically: Version 4 UUIDs are random, so they have no ordering. Sorting by one gives an arbitrary order, which is a common surprise when they are used as database keys.

Privacy and your data

Values are generated on your device and never transmitted. Nothing is stored, and generated identifiers are never included in analytics.

Frequently asked questions

How likely is a UUID collision?: Vanishingly unlikely. A version-4 UUID carries 122 random bits, so you would need to generate on the order of a billion UUIDs per second for decades before a collision became a realistic concern. For ordinary application use you can treat them as unique.
Can I use a UUID as a security token?: It is better not to. A v4 UUID is unpredictable, but it is designed as an identifier — it is often logged, put in URLs, and shared between systems, and it has no expiry or revocation. Use a purpose-built token or session mechanism for anything that grants access.