UUID Generator: Complete Guide to Unique Identifiers (UUID, NanoID, ULID)

What Is a UUID

A UUID (Universally Unique Identifier) is a 128-bit identifier designed to be globally unique without central coordination. The standard format is:

550e8400-e29b-41d4-a716-446655440000

36 characters total (including 4 hyphens), divided into 5 segments of hexadecimal digits.

UUID Versions

UUID v4 (Random)

The most widely used version, generated entirely from random numbers. The collision probability is astronomically low — generating 10 trillion UUIDs gives only a 50% chance of collision.

Format: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
        (4 = version, y = 8/9/a/b)

Best for: Database primary keys, session IDs, API request tracing

UUID v1 (Timestamp + MAC)

Uses the current timestamp and machine MAC address. Contains time information but exposes the MAC address — a privacy concern.

UUID v5 (Namespace-based)

Uses SHA-1 hashing of a namespace + name to produce deterministic UUIDs. The same input always yields the same output.

Best for: Scenarios requiring reproducible IDs (e.g., URL identification)

NanoID: A Shorter Alternative

NanoID is a configurable-length ID generator using URL-friendly characters (A-Za-z0-9_-), handy for mock datasets alongside a lorem ipsum generator:

NanoID (21 chars): V1StGXR8_Z5jdHi6B-myT

Comparison with UUID v4:

ULID: Sortable Unique IDs

ULID (Universally Unique Lexicographically Sortable Identifier) combines a timestamp with random data, enabling time-based sorting:

Format: 01ARZ3NDEKTSV4RRFFQ69G5FAV (26 chars, Crockford Base32)

Best for: Primary keys requiring chronological ordering, log tracing

How to Choose an ID Scheme

Using an Online UUID Generator

ToolVault's UUID Generator supports:

• UUID v4: One-click generation, copy-ready
• NanoID: Customizable length and character set
• ULID: Time-stamped, sortable IDs
• Batch generation: Create multiple IDs at once

UUIDv7: why time-ordered is eating the database world

v4 (random) scatters inserts across the entire B-tree — every insert is a random page write, cache misses at scale. v7 fixes this by putting a 48-bit millisecond timestamp in the high bits: keys arrive in ascending order, inserts hit the rightmost pages, and the tree stays hot. The measured effect at insert-heavy workloads is substantial write-amplification reduction. v7 went from draft to RFC 9562 formal standard in 2024 — the "is it stable enough?" question is settled. The one caveat: timestamp-ordered IDs leak creation time (when the record was made). For systems where that is sensitive (session tokens, URL-visible IDs), v4's opacity remains the right call; for internal primary keys, v7 is now the default recommendation. The generator supports both plus ULID (same idea, Crockford-encodable, 26 chars) for cross-system comparison.

The collision math, without hand-waving

v4 has 122 random bits. The birthday-bound answer: you need to generate 2.7 trillion v4 UUIDs for a 1-in-a-billion collision chance — not "impossible", but 2.7 trillion is roughly a thousand UUIDs per second for a hundred years from a single system. The real-world collision risk is not the algorithm: it is duplicate-generation bugs (two machines with the same poorly-seeded PRNG after a VM clone — the 1999 Kerberos incident was exactly this) and copy-paste duplication in databases without unique constraints. Keep the unique index even though "UUIDs never collide"; the index is cheap insurance against the actual failure modes.

Storing UUIDs: the format tax

A UUID stored as its 36-character text form costs 36 bytes plus per-row overhead; as a native uuid type (Postgres) or 16-byte binary, it costs 16. On a hundred-million-row table that difference is gigabytes and measurable index depth. MySQL has no native UUID type (store as BINARY(16) and convert at the boundary with UUID_TO_BIN/BIN_TO_UUID; the swap flag reorders for time-locality). Application-side, Java's UUID and .NET's Guid are already 128-bit values — serializing them to strings for the database forfeits the format for no benefit.

Real-world integration pitfalls

1. Frontend generates v4, backend validates as v1: the version nibble check rejects everything. Pick one version per system and validate at the schema layer.
2. Case sensitivity: standard UUIDs are lowercase, but some systems accept and store uppercase mixed forms. Normalize with toLowerCase() before comparison or storage.
3. Missing hyphens: some APIs return 32-char hex without hyphens; parsers expecting the 36-char format crash. Normalize first: s.replace(/-/g, '').toLowerCase(), then reformat.

Implementer's note

This site's UUID generator uses crypto.getRandomValues for 128-bit randomness, formatted per RFC 9562. v7 mode writes the current millisecond timestamp into the high 48 bits; the remaining 74 bits are random. ULID uses Crockford Base32 encoding. Batch generation calls getRandomValues per UUID (128 bits each) without seed caching — avoiding the classic post-VM-clone identical-seed incident.

FAQ

How Likely Is a UUID Collision?

UUID v4 has a space of 2^128 ≈ 3.4×10^38. Generating 1 billion UUIDs yields a collision probability of roughly 10^-18 (virtually zero). No UUID collision has ever been confirmed in practice.

Is NanoID More Secure Than UUID?

It depends on length and character set. A 21-character NanoID (64-char set) has ~126 bits of entropy — close to UUID v4's 128 bits. Choose a sufficiently long NanoID.

Why Is ULID Better Than UUID for Database Keys?

Database indexes (e.g., B+Tree) are more efficient with sequential inserts. UUID v4 is fully random, causing page splits on every insert. ULID is time-ordered, so the insertion pattern is closer to sequential writes, yielding better performance.

This article is brought to you by ToolVault. The homepage collects more browser-local tools.