UUID Generator

Generate UUID v1, v4, v7 — bulk generation, validation & formatting

UUID Validator

All UUID Versions

  • v1 — Gregorian timestamp + node
  • v3 — MD5(namespace + name)
  • v4 — Cryptographically random
  • v5 — SHA-1(namespace + name)
  • v6 — Reordered timestamp (sortable)
  • v7 — Unix ms timestamp + random
  • NIL — All zeros (null value)
  • MAX — All ones (RFC 9562)

Free UUID Generator — v1, v4, v7

Generate universally unique identifiers (UUIDs) in v1 (timestamp-based), v4 (cryptographically random) and v7 (Unix millisecond sortable) formats. All UUIDs are generated using the Web Crypto API for true randomness. Includes bulk generation and UUID validation.

Features

Three UUID Versions

v1 (timestamp + MAC), v4 (random), v7 (Unix ms, sortable) and NIL (all zeros).

Bulk Generation

Generate up to 100 UUIDs at once and copy all with a single click.

UUID Validator

Validates UUID format and identifies the version from any pasted UUID.

Format Options

Output with/without hyphens, in {braces}, uppercase or lowercase.

One-Click Copy

Copy individual UUIDs or the entire bulk list to clipboard instantly.

Cryptographically Secure

v4 generation uses crypto.getRandomValues() — never Math.random().

Who Uses This Tool?

DevelopersGenerate unique IDs for database records, API resources and session tokens.
Database AdministratorsCreate primary keys for distributed databases where auto-increment is impractical.
DevOps EngineersGenerate unique identifiers for cloud resources, containers and microservices.
Security ProfessionalsGenerate unique tokens for password reset links, email verification and API keys.

Common Questions

What is the difference between UUID v1 and v4?
v1 includes the timestamp and a MAC address component, making each UUID time-ordered but potentially leaking machine information. v4 is purely random and is the most commonly used format.
When should I use UUID v7?
v7 encodes a Unix millisecond timestamp in the most significant bits, making UUIDs naturally sortable by creation time. This is ideal for database primary keys where chronological ordering matters for index performance.
Are UUIDs guaranteed to be unique?
v4 UUIDs have 122 bits of randomness, giving a collision probability of 1 in 5.3×10³⁶. In practice they are treated as globally unique. The mathematical likelihood of a collision is negligible in any realistic system.
Can I use a UUID as a database primary key?
Yes — UUIDs are excellent primary keys for distributed systems. v7 UUIDs are preferred because their time-ordering reduces index fragmentation in databases like PostgreSQL and MySQL.

Pro Tip

For new distributed systems, prefer UUID v7 over v4 as your primary key. The time-ordered nature of v7 significantly reduces B-tree index fragmentation in relational databases, improving INSERT performance by 2–5× at scale compared to random v4 UUIDs.

Did You Know?

5.3 × 10³⁶
Possible UUID v4 Values
UUID v4 has 2^122 = 5.3 × 10^36 possible values. If you generated 1 billion UUIDs per second for the entire age of the universe (13.8 billion years), the probability of a single collision would still be essentially zero.
1997
UUID Standard Published
The UUID specification was first proposed in the Apollo NCA RPC system in the 1980s and standardised in RFC 4122 in 2005. They were widely adopted for distributed database primary keys before that.
~36 chars
UUID Always the Same Length
Every UUID (regardless of version) is exactly 128 bits, displayed as 32 hexadecimal characters plus 4 hyphens = 36 characters total. The fixed length makes them reliable for database column sizing and API design.

UUID Version Comparison

VersionMethodSortable?Deterministic?Best Use Case
v4Random (crypto)NoNoGeneral purpose IDs, tokens, keys
v7Unix ms + randomYes (ms)NoDB primary keys, time-sorted IDs
v6Reordered timestampYes (100ns)NoUpgrade of v1, sortable IDs
v1Gregorian ts + nodeYes (100ns)NoLegacy systems only
v5SHA-1(ns + name)NoYesStable IDs from existing data
v3MD5(ns + name)NoYesLegacy v5 equivalent (avoid)
NILAll zerosN/AN/ANull/empty UUID placeholder
MAXAll onesN/AN/AMax/end-of-range sentinel value

You May Also Ask

Why do UUIDs have different versions (v1, v4, v7)?
Each version uses different data sources. v1 uses timestamp + MAC address (time-ordered but reveals machine info). v3 uses MD5 hash of namespace + name (deterministic). v4 uses pure randomness (most common). v5 uses SHA-1 hash of namespace + name. v7 uses Unix millisecond timestamp + randomness (sortable). Choose based on whether you need randomness, sortability or determinism.
Should I use UUID as a database primary key?
Yes, especially for distributed systems. Traditional auto-increment integers only work on a single database — they conflict when merging databases or scaling horizontally. UUIDs are globally unique across all databases and servers. The trade-off: UUIDs are larger (16 bytes vs 4–8 bytes for integers) and random v4 UUIDs cause index fragmentation. Use v7 for better index performance.
What is the NIL UUID and when is it used?
The NIL UUID is 00000000-0000-0000-0000-000000000000 — all 128 bits set to zero. It is used as a "null" or "empty" identifier in systems where a UUID field is required but no meaningful value exists. It should never be assigned to a real entity; treat it as equivalent to null/undefined.

Common Mistakes

Using UUID v1 in security-sensitive contexts
UUID v1 encodes your MAC address and timestamp, potentially revealing when and on which machine an ID was created.
Use v4 or v7 when user privacy or system anonymity matters.
Storing UUIDs as strings instead of binary
UUIDs stored as VARCHAR(36) strings use 36 bytes. Stored as BINARY(16) they use 16 bytes — 56% less storage, faster indexing.
Store UUIDs as BINARY(16) in databases; only convert to string for display.
Assuming short IDs are safe alternatives
Services that shorten UUIDs for user-facing URLs (like "abc123") often reduce entropy enough to make sequential guessing feasible.
If exposing IDs externally, use full 128-bit UUIDs or add additional access controls.