HomeDeveloper ToolsUUID Generator

unique ids. one click.

generate v4 UUIDs instantly. single or bulk mode — up to 100 at once. cryptographically secure.

v4
cf385c10-3890-44d2-a237-2283c4bfe812
UUIDs (1–100)

What this generates

Version 4 UUIDs — 128-bit identifiers where 122 of the bits are cryptographically random. Single mode for one-off needs, bulk mode for up to 100 at a time. Generated in your browser using crypto.randomUUID() when available, or a crypto.getRandomValues() fallback on older browsers.

Why v4 specifically

The UUID standard defines several versions. The two anyone actually uses are:

  • v4 — random. 122 bits of randomness, no information about when or where it was generated. The default for most modern systems.
  • v7 — time-ordered random. The first 48 bits are a Unix millisecond timestamp; the rest is random. Newer (standardized in 2024) and offers better database insert performance, but ecosystem support is still patchy in 2026.

v4 is the right default when you need an opaque identifier with maximum compatibility. If you are generating IDs at high volume into an indexed database column, v7 (or its older cousin ULID) becomes worth considering. We wrote a longer comparison piece on the trade-offs: Choosing v4 UUIDs vs ULIDs vs nanoid.

Collision probability, in the form people ask for

With 122 random bits, the question “when do I have a 50% chance of any two UUIDs colliding?” has the same shape as the birthday paradox. The answer is roughly 2.71 × 1018 UUIDs — about 2.7 quintillion. At the scale of one billion UUIDs generated per second continuously, that threshold takes about 86 years to reach.

For practical use, that means: do not worry about it. Generating UUIDs to identify users, requests, log events, cache entries, file uploads — all of those will run for the lifetime of any application without colliding once. The collision math becomes interesting only at planet-scale write rates that essentially no individual application produces.

The format, anatomized

text
f47ac10b-58cc-4372-a567-0e02b2c3d479
^^^^^^^^ ^^^^ ^^^^ ^^^^ ^^^^^^^^^^^^
   8      4    4    4       12

The "4" at the start of the third group is the version field.
The first hex digit of the fourth group encodes the variant
(should be 8, 9, a, or b for RFC-compliant UUIDs).

The dashes are not random — they fall at fixed byte positions. Some systems strip them and store UUIDs as 32 hex characters; others store them as raw 16 bytes. All three representations encode the same value.

Where the randomness comes from

crypto.randomUUID()draws from your operating system's cryptographic random source — on Linux it is /dev/urandom, on macOS and Windows it is the equivalent OS-managed pool. That source aggregates hardware noise (CPU thermal jitter, interrupt timing, mouse movement entropy) into a stream that is unpredictable even to an attacker who can observe many outputs.

Critically, the generator does not use Math.random(), which is fast but statistically predictable. UUIDs generated from Math.random() can collide much sooner than the 122-bit math suggests, and have been the cause of several real-world incidents in JavaScript apps.

If you have legacy IDs from a Math.random source

The UUIDs themselves are still well-formed — the issue is only the size of the keyspace they were drawn from. Existing IDs in your database are fine to keep. New IDs should come from a secure source going forward, and there is no harm in mixing the two.

Bulk mode

Bulk mode generates up to 100 UUIDs at a time, one per line, copyable as a block. Useful for seeding test data, populating a fixture file, generating invite codes (though a shorter format is usually nicer for that use case — see the blog post for nanoid), or any case where you would otherwise be clicking “generate” in a loop.

Each UUID in a bulk run is generated independently. There is no relationship between consecutive UUIDs, no incrementing counter, and no shared seed — the security guarantees of a single UUID apply equally to every UUID in a batch.

Privacy

Generation happens entirely in your browser. The UUIDs you generate are never sent to a server, logged, or stored on Persimmon's side. If you generate a hundred UUIDs and close the tab, no record of them existed anywhere outside your machine.

What this generates

Version 4 UUIDs — 128-bit identifiers where 122 of the bits are cryptographically random. Single mode for one-off needs, bulk mode for up to 100 at a time. Generated in your browser using crypto.randomUUID() when available, or a crypto.getRandomValues() fallback on older browsers.

Why v4 specifically

The UUID standard defines several versions. The two anyone actually uses are:

  • v4 — random. 122 bits of randomness, no information about when or where it was generated. The default for most modern systems.
  • v7 — time-ordered random. The first 48 bits are a Unix millisecond timestamp; the rest is random. Newer (standardized in 2024) and offers better database insert performance, but ecosystem support is still patchy in 2026.

v4 is the right default when you need an opaque identifier with maximum compatibility. If you are generating IDs at high volume into an indexed database column, v7 (or its older cousin ULID) becomes worth considering. We wrote a longer comparison piece on the trade-offs: Choosing v4 UUIDs vs ULIDs vs nanoid.

Collision probability, in the form people ask for

With 122 random bits, the question “when do I have a 50% chance of any two UUIDs colliding?” has the same shape as the birthday paradox. The answer is roughly 2.71 × 1018 UUIDs — about 2.7 quintillion. At the scale of one billion UUIDs generated per second continuously, that threshold takes about 86 years to reach.

For practical use, that means: do not worry about it. Generating UUIDs to identify users, requests, log events, cache entries, file uploads — all of those will run for the lifetime of any application without colliding once. The collision math becomes interesting only at planet-scale write rates that essentially no individual application produces.

The format, anatomized

text
f47ac10b-58cc-4372-a567-0e02b2c3d479
^^^^^^^^ ^^^^ ^^^^ ^^^^ ^^^^^^^^^^^^
   8      4    4    4       12

The "4" at the start of the third group is the version field.
The first hex digit of the fourth group encodes the variant
(should be 8, 9, a, or b for RFC-compliant UUIDs).

The dashes are not random — they fall at fixed byte positions. Some systems strip them and store UUIDs as 32 hex characters; others store them as raw 16 bytes. All three representations encode the same value.

Where the randomness comes from

crypto.randomUUID()draws from your operating system's cryptographic random source — on Linux it is /dev/urandom, on macOS and Windows it is the equivalent OS-managed pool. That source aggregates hardware noise (CPU thermal jitter, interrupt timing, mouse movement entropy) into a stream that is unpredictable even to an attacker who can observe many outputs.

Critically, the generator does not use Math.random(), which is fast but statistically predictable. UUIDs generated from Math.random() can collide much sooner than the 122-bit math suggests, and have been the cause of several real-world incidents in JavaScript apps.

If you have legacy IDs from a Math.random source

The UUIDs themselves are still well-formed — the issue is only the size of the keyspace they were drawn from. Existing IDs in your database are fine to keep. New IDs should come from a secure source going forward, and there is no harm in mixing the two.

Bulk mode

Bulk mode generates up to 100 UUIDs at a time, one per line, copyable as a block. Useful for seeding test data, populating a fixture file, generating invite codes (though a shorter format is usually nicer for that use case — see the blog post for nanoid), or any case where you would otherwise be clicking “generate” in a loop.

Each UUID in a bulk run is generated independently. There is no relationship between consecutive UUIDs, no incrementing counter, and no shared seed — the security guarantees of a single UUID apply equally to every UUID in a batch.

Privacy

Generation happens entirely in your browser. The UUIDs you generate are never sent to a server, logged, or stored on Persimmon's side. If you generate a hundred UUIDs and close the tab, no record of them existed anywhere outside your machine.

more free tools

PDF utilities, image tools, developer helpers — all free, no signup.

Something wrong?