What is UUID v4?
UUID v4 is a 128-bit identifier built from 122 bits of cryptographically secure randomness, with the remaining bits fixed to mark the version and variant. It reveals nothing about when or where it was created, which makes it the right choice for anything user-facing where creation order could leak information: session tokens, share links, and password-reset URLs.
This generator uses the browser’s native crypto.randomUUID(), which is RFC 9562-compliant and backed by a cryptographically secure random source — never Math.random(). Generation happens entirely in your browser; the value never reaches our server.
UUID v4 structure
UUID v4 occupies 128 bits. Six of those bits are fixed: four mark the version (0100 in binary, producing the 4 at position 13 of the string) and two mark the RFC 9562 variant (10 in binary, producing 8, 9, a, or b at position 17). The remaining 122 bits are drawn from the platform’s CSPRNG — crypto.randomUUID() in browsers and Node.js, os.urandom() in Python, crypto/rand in Go.
xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx
^ ^
| variant (RFC 9562)
version 4
That 122-bit random payload means the pool of possible v4 UUIDs is 2¹²² ≈ 5.3 × 10³⁶. You would need to generate approximately 2.7 × 10¹⁸ UUIDs before a collision becomes statistically likely — a number far beyond any realistic generation rate.
When to use UUID v4
UUID v4 is the right choice when the ID will be visible outside your system — in a URL, an API response, a share link, or a password-reset token — and the creation time or sequence of records must not be inferrable by anyone who sees it. Because v4 carries no timestamp, an observer who collects many v4 UUIDs learns nothing about when they were created or how many others were created around the same time.
Common uses: user-facing record IDs in URLs, session identifiers, idempotency keys for API requests, one-time tokens, file upload IDs, invite links.
When to use UUID v7 instead
If the ID is an internal database primary key and you don’t need to hide creation order, UUID v7 is a better choice. Its 48-bit timestamp prefix means inserts append to the end of a B-tree index rather than scattering across it — a significant performance difference at scale. PostgreSQL 18 ships uuidv7() natively, and most ORMs treat both versions as opaque 16-byte values requiring no code change.
For the full comparison — index behaviour, what v7’s timestamp discloses, and migration — see UUID v4 vs UUID v7.
New to these identifiers? Start with what a UUID is and how the format works.
How this tool works
Every UUID is generated entirely in your browser and never sent to our
server. The randomness comes from the Web Crypto API
(crypto.randomUUID() for v4, crypto.getRandomValues()
for v7) — never Math.random() — so the values are
cryptographically unique. The generated ID exists only on your screen and in
your clipboard: it is never transmitted, stored, or logged.
The site itself loads Google Tag Manager to count anonymous page and feature usage, which sets cookies. That measurement never includes the UUIDs you generate.
Frequently asked questions
Is a UUID guaranteed to be unique?
Not mathematically guaranteed, but the collision probability is so small it's treated as unique in practice. You'd need to generate billions of v4 UUIDs before a collision became likely.
Are these UUIDs cryptographically secure?
The randomness is, yes — it comes from the Web Crypto API. That said, a UUID is an identifier, not a secret; don't use one as a password or an unguessable capability token on its own.
Does this tool store or log my UUIDs?
No. Generation happens in your browser and the value never reaches our server. The UUID itself is never transmitted or recorded.
Is UUID v4 random enough to be unpredictable?
v4 uses 122 bits of cryptographically secure randomness from the Web Crypto API, so guessing a specific value is infeasible. It is still an identifier, not a secret — do not rely on it alone as an access token.