Developer

Encoders, converters & dev utilities

12 tools
Developer · United States

UUID Generator

Generate UUID v4, v7 & nil — single or bulk, with format options. Accurate, instant and free — for United States.

Generated with your browser's cryptographic RNG

Every UUID is produced with your browser's cryptographic RNG (CSPRNG) crypto.getRandomValues, never Math.random(). Everything runs on your device; nothing is sent to a server.
Version

What these mean:

1–1000
Format

Which version should I use?

v4 is fully random — the safe default when you just need a unique id. v7 puts a millisecond timestamp in the leading bits, so v7 ids sort in creation order and cluster well as a database primary key. The nilUUID is all zeros — a conventional placeholder for "no value".
Anatomy

What a UUID is

A UUID is a 128-bit value written as 32 hexadecimal digits in the canonical 8-4-4-4-12 form — 36 characters including the hyphens. It lets independent systems mint identifiers without a central coordinator. The format is standardised by RFC 9562 (2024), which obsoleted RFC 4122 and added versions 6, 7 and 8.

A UUID at a glance
Size
128 bits
Text form
8-4-4-4-12 hex (36 chars)
Version digit
13th hex position
Standard
RFC 9562
Versions

Which version should I use — v4, v7 or nil?

The version lives in the 13th hex digit. For new work you are really choosing between random v4 and time-ordered v7.

v4 — random

122 random bits

  • Fully random, opaque
  • The everyday default
  • Best for tokens that leak nothing

v7 — time-ordered

48-bit ms timestamp + random

  • Sorts in creation order
  • Ideal database primary key
  • Avoids B-tree index fragmentation

nil

All zeros

  • 00000000-…
  • A sentinel for "no value"
  • Never a real identifier

v7 is the modern pick for DB keys

Because a v7's leading bits are a millisecond timestamp, new rows insert at the right edge of a B-tree index instead of scattering like random v4. That keeps write throughput and cache locality high and avoids the page splits that random keys cause — the reason teams are moving new primary keys from v4 to v7.
Correctness

CSPRNG, not Math.random() — and an honest word on uniqueness

The unpredictability and collision-resistance of a UUID depend entirely on the quality of its random bits. This tool draws them from your browser's cryptographically secure RNG crypto.getRandomValues() and crypto.randomUUID() — never Math.random().

CSPRNG

What this tool uses

  • Unpredictable, evenly distributed
  • Fit for ids and tokens
  • Native Web Crypto API

Math.random()

Never for ids

  • Not cryptographically secure
  • Can be predictable
  • Raises collision & guess risk

Practically unique, not guaranteed

A v4 UUID has 122 random bits, so a collision is astronomically unlikely — but not mathematically impossible. Treat UUIDs as collision-resistant, not collision-proof; the honest claim is "unique enough for any real workload".
FAQ

Frequently asked questions

A UUID (Universally Unique Identifier) is a 128-bit value written as 32 hexadecimal digits in the canonical 8-4-4-4-12 form, for example f47ac10b-58cc-4372-a567-0e02b2c3d479 (36 characters including the hyphens). UUIDs let independent systems mint identifiers — database primary keys, correlation IDs, idempotency keys, request-trace IDs — without a central coordinator, because the odds of two randomly generated values colliding are astronomically small. The format is standardised by RFC 9562, which in 2024 obsoleted the older RFC 4122 and added versions 6, 7 and 8.

v4 is fully random — the everyday default when you just need an opaque unique id. v7 is time-ordered: its leading 48 bits are a Unix-millisecond timestamp, so v7 values sort in creation order. That makes v7 an excellent database primary key — new rows land at the right edge of a B-tree index instead of scattering like random v4, avoiding index fragmentation and page splits. The nilUUID is all zeros — a conventional placeholder meaning "no value".

Use v7 for new database primary keys and any id where sortable-by-creation-time helps (it keeps index writes fast and preserves rough ordering). Use v4 for opaque random tokens where you do not want any information leaked by the id. Use the nil UUID as a sentinel for "no id yet". Older v1 is time-based but embeds the machine MAC address and is generally only needed for legacy interop — this tool focuses on the two versions worth choosing today, v4 and v7, plus nil.

No — they are practically unique, not mathematically guaranteed. A v4 UUID has 122 random bits, so the probability of a collision is astronomically small: you would need to generate on the order of a billion UUIDs per second for about 85 years to reach a 50% chance of a single duplicate. For essentially every application this is safe to treat as unique, but the honest statement is "collision-resistant", not "impossible". v7 lowers collision odds further within a run by combining a timestamp with random bits.

The uniqueness and unpredictability of a UUID depend entirely on the quality of its random bits. This tool uses your browser's cryptographically secure random number generator — crypto.getRandomValues() and crypto.randomUUID() — which is designed to be unpredictable and evenly distributed. Math.random() is not cryptographically secure: its output can be predictable and is not intended for identifiers or tokens, which raises both collision and guessability risk. This generator never uses Math.random().

Yes. GUID (Globally Unique Identifier) is Microsoft's name for the same 128-bit identifier defined by RFC 9562; the two terms are interchangeable. The .NET and Windows world often writes them in braces and/or uppercase, for example {F47AC10B-58CC-4372-A567-0E02B2C3D479}. This tool offers braces and uppercase toggles so you can emit either the standard lowercase-hyphenated UUID form or the GUID style your platform expects.

No. Every UUID is generated entirely in your browser using the native Web Crypto API — nothing is uploaded, logged or stored, and the tool works offline once loaded. Bulk generation, copy and the .txt download all run on your device.

Sources

Method, standards & references

Method: UUIDs are generated per RFC 9562 — v4 from 122 CSPRNG bits with version nibble 4 and the 10xxvariant; v7 from a 48-bit big-endian Unix-millisecond timestamp plus random bits with version nibble 7; nil as all zeros. All random bits come from the browser's Web Crypto API (crypto.getRandomValues / crypto.randomUUID), never Math.random(). Nothing is sent to a server.

How we calculate this

Reviewed by Reckonist Editorial · Last reviewed 4 July 2026. Figures follow the methods and sources set out in our editorial standards.

This tool generates RFC 9562 UUIDs locally in your browser using the native Web Crypto API. UUIDs are collision-resistant, not mathematically guaranteed to be unique; use appropriate database constraints for critical uniqueness.

Keep going

Same-category tools follow this colour; a cross-category link keeps its own.