uniqueid.tech

UUID v4 Generator

Generate one or many random UUID v4 values in your browser. Output format, case, and language literal wrapping are all configurable. Nothing leaves your device.

Output options
Case
Bulk delimiter 
Click Generate to produce UUIDs.

What is a UUID v4?

A UUID v4 is a 128-bit identifier in which 122 bits are cryptographically random and 6 bits are reserved for the version (4) and the variant marker defined by RFC 9562. The randomness gives roughly 5.3 × 1036 possible values, which is enough that collisions are negligible at internet scale.

In .NET, Guid.NewGuid() produces a v4 UUID seeded from the operating system's cryptographic RNG (BCryptGenRandom on Windows, /dev/urandom on Linux). Calls to this site use the same call — no custom RNG, no entropy starvation concerns.

When to use v4

  • You need an unguessable identifier (session tokens, share links, public IDs).
  • You need coordination-free generation — any number of independent services, clients, or devices can mint v4 IDs with no shared state and no collision risk. For how that compares with Snowflake, UUID v7, and ULID, see generating IDs in distributed systems.
  • Sortability and database insert performance are not concerns. If they are, consider UUID v7.
  • You're working with a system that already standardised on v4 and you have no reason to deviate.

Generating v4 in code

C#

var id = Guid.NewGuid();
// 47a493a5-85fd-434a-895b-aa2631ec6aa2

Python

import uuid
id = uuid.uuid4()

JavaScript (Web Crypto)

const id = crypto.randomUUID();

FAQ

Is it really safe to generate UUIDs in the browser?
Yes. This page uses .NET's Guid.NewGuid(), which inside the Blazor WebAssembly runtime is implemented on top of the browser's crypto.getRandomValues() — a CSPRNG mandated by the Web Crypto Spec. The randomness quality is equivalent to a server-side BCryptGenRandom call.
Will I ever get a duplicate UUID?
With 122 random bits, you would need to generate roughly 2.71 quintillion UUIDs before the probability of a collision reached one in a billion. In practice, no.
Can I use UUID v4 as a database primary key?
You can, but with caveats. Random v4 values land at unpredictable pages in a B-tree primary key index — every insert risks a page split and the index loses cache locality. For high-write tables, prefer UUID v7. For low-write tables, or where you specifically don't want IDs to reveal creation order, v4 is fine. For the full comparison against integer keys, see UUID vs auto-increment primary keys.
Can UUID v4 be guessed or predicted?
Not when the underlying RNG is cryptographic. 122 bits of CSPRNG output is well beyond brute-force range. The risk is in the generator: a weak PRNG (for example, JavaScript's Math.random) can be state-recovered from a handful of outputs, letting an attacker predict the rest. For security-sensitive IDs, use a CSPRNG-backed v4 — this generator does.
Should I use v4 or v7?
For database primary keys: v7, because its time-ordered bytes give B-tree indexes locality of reference. For everything else (tokens, public IDs, anywhere the value should be unguessable): v4.
An unhandled error has occurred. Reload ×