UUID Generator

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 4122. It is formatted as 32 hexadecimal digits separated by hyphens in the pattern xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. UUIDs are designed to be unique across all space and time without requiring a central authority to issue them.

UUID v4, the most commonly used version, is randomly generated. With 122 random bits, the probability of generating two identical UUIDs is astronomically low — roughly 1 in 5.3 × 10³⁶. This makes UUID v4 safe to use as primary keys in distributed systems, session tokens, file names, and anywhere a collision-free unique ID is needed.

When to Use UUIDs

• Database primary keys — UUIDs allow records to be created across multiple services or clients without coordination, making them ideal for distributed architectures and microservices.
• File and asset naming — Use UUIDs as file names to avoid collisions when users upload files with the same name.
• Session and request IDs — Track user sessions, API requests, or background jobs with UUID-based correlation IDs for easier debugging.
• Test fixtures and seed data — Generate predictable sets of UUIDs for test databases or mock API responses.

UUID v4 vs Other Versions

UUID v1 uses the current timestamp and MAC address, making it sortable but potentially revealing machine identity. UUID v3 and v5 are deterministic, derived from a namespace and name using MD5 or SHA-1 hashing. UUID v4 is purely random and the best choice when you need unpredictable, collision-resistant identifiers.

UUID v4 vs Auto-Increment Integers

A frequent design question is whether to use UUIDs or simple auto-increment integers as primary keys. Each choice has real trade-offs that go beyond personal preference.

• Generation location. UUIDs can be created on the client, in a worker queue, or on the server without coordination — useful for offline-first apps and event-sourced systems. Auto-increment IDs require a round-trip to the database before the row exists.
• Information leakage. Sequential integers reveal record count and growth rate to anyone who sees a URL like /orders/4218. UUIDs leak nothing.
• Index size and locality. A 128-bit UUID is four times the size of a 32-bit integer in B-tree indexes, and random UUIDs hurt insertion locality. For high-throughput tables, consider UUID v7 (time-ordered) or store UUIDs as binary instead of text.
• Foreign-key debugging. Joining tables by integer ID is faster to read at a glance. With UUIDs, copying full identifiers into queries is the norm and tooling has adapted.

Practical Tips for Working with UUIDs

A few small habits make UUIDs much easier to live with in production codebases:

• Use the native database type. PostgreSQL has a built-in uuidcolumn type that stores the value as 16 bytes, indexes efficiently, and prints in the canonical hyphenated form. Storing UUIDs as VARCHAR(36) wastes space and slows index lookups.
• Lowercase consistency. RFC 4122 allows either case, but mixing 550E8400-E29B-... and 550e8400-e29b-... in the same system causes subtle bugs in string comparisons. Normalise to lowercase at the application boundary.
• Validate before parsing. Reject inputs that do not match the canonical pattern early. Many SQL injection and lookup-by-id bugs hide behind permissive UUID parsing.
• Log UUIDs alongside operations. Correlate front-end actions, API requests, queue jobs, and database writes with a shared request-UUID for fast distributed-trace debugging.

Frequently Asked Questions