UUID Generator

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit identifier defined by RFC 4122 / RFC 9562. It can be generated independently with a near-zero collision probability, making it ideal for database primary keys, distributed systems, and file identifiers.

Versions at a glance

• v4 (random) - 122 random bits. The most common variant; unpredictable. Collision probability is effectively zero.
• v7 (time-based, recommended) - The first 48 bits are a Unix millisecond timestamp, so values sort in time order. Database-index friendly and recommended over v4 in modern systems.
• NIL - All bits set to zero (00000000-0000-0000-0000-000000000000). Used to represent an "empty" UUID.

Why prefer v7?

UUID v4 is fully random and tends to fragment B-tree indexes when inserted into databases. v7 is monotonically increasing in time, so new rows append to the end of the index - better INSERT performance, and you can recover the creation time directly from the UUID.

To embed UUIDs in JSON payloads, use the JSON Formatter & Converter. To use a UUID as the @id value in structured data, see the JSON-LD Generator.

UUID Misconceptions and Pitfalls

UUIDs are nearly inexhaustible to generate, but used carelessly they can quietly degrade database performance or introduce security issues.

The "v4 UUIDs never collide" misconception

v4 draws from 122 random bits, making collision probability vanishingly small - but not mathematically zero. In high-scale systems, pairing UUID columns with a database UNIQUE constraint is still the safe choice. Also, weak random sources like Math.random() make UUIDs predictable and unsuitable as security tokens. Always use a cryptographically secure source (crypto.getRandomValues or crypto.randomUUID).

Pitfalls when using UUIDs as a database primary key

• v4 index fragmentation - Random insertion order causes frequent B-tree page splits, hurting write performance and inflating index size. v7 (time-ordered) avoids this.
• Storing as a string vs. binary - A UUID stored as a 36-character string takes 36 bytes (with hyphens). Using MySQL's BINARY(16) or PostgreSQL's uuid type cuts that to 16 bytes, shrinking index size and improving lookup speed.
• JOIN performance - UUID columns are 2-4x wider than 4- or 8-byte integer IDs. For tables with heavy JOINs, consider an integer surrogate key plus a separate UUID column.
• Exposing UUIDs in URLs - v4 is safe to expose (it is unguessable), but 36 characters makes URLs long. If short identifiers matter, consider nanoid or base62 encoding.

Version selection guide

Frequent mistakes

• Using UUID directly as a password reset token - v4 is fine, but v1, v3, and v5 are predictable. For security-sensitive tokens, use v4 or a dedicated secure random function.
• Case-sensitive comparisons - UUID text representation is case-insensitive (F47AC10B and f47ac10b are the same value). Inconsistent casing can produce apparent duplicates in string comparisons.
• Mixing hyphenated and non-hyphenated forms - f47ac10b-58cc-... and f47ac10b58cc... are the same UUID but different strings. Standardize the storage format.
• Using v1 - v1 embeds the host MAC address, making the generating machine identifiable. Avoid it for privacy and security reasons.

FAQ