Overview
A UUID (Universally Unique Identifier) is a 128-bit value used to identify records, sessions, requests, and resources without relying on a central authority to hand out sequential numbers. Every modern programming language and database has built-in or library support for generating them, but the choice between UUID versions — and the decision of whether to use a UUID at all instead of an auto-increment integer — has real performance and design consequences. This guide covers the format, the version choice, generation in code, validation, and the trade-offs against simpler ID schemes.
Use the UUID Generator for instant generation in the browser, and the UUID Validator to check the format of any UUID you receive from elsewhere.
What You Need
- No special tools are required to generate a UUID using a browser-based tool
- For code-based generation: a JavaScript/Node.js, Python, or other language runtime with UUID support (most modern languages have this built in or via a standard library)
- A basic understanding of what the UUID will identify (a database row, a session token, a distributed request ID) to choose the right version
Step 1: Understand the UUID Format
A UUID is a 128-bit value, almost always represented as 32 hexadecimal digits arranged in five groups separated by hyphens, following an 8-4-4-4-12 pattern:
550e8400-e29b-41d4-a716-446655440000
The total string is always 36 characters including the four hyphens. The version of the UUID is encoded in the first character of the third group — in the example above, the 4 in 41d4 marks this as a version 4 UUID. A separate variant field (the first one or two bits of the fourth group) indicates which UUID specification variant is in use, with 8, 9, a, or b as the leading character being the standard RFC variant used by virtually all modern UUID implementations.
Step 2: Choose the Right UUID Version
Several UUID versions exist, but three matter for most practical use cases today:
- Version 4 (random): Generated from 122 bits of randomness (the remaining 6 bits are fixed version and variant markers). This is the most widely used version because it requires no coordination, no machine-specific data, and no timestamp — just a secure random number generator. Use v4 when you need a simple, general-purpose unique identifier with no ordering requirement.
- Version 1 (timestamp + MAC address): Combines the generating machine's MAC address with a high-precision timestamp. This version has fallen out of favour because it leaks machine-identifying information and generation time, which is a privacy and security concern when UUIDs are exposed externally.
- Version 7 (timestamp-prefixed + random): Combines a 48-bit millisecond-precision timestamp with random bits for the remainder. This makes v7 UUIDs naturally sortable by creation order, which is increasingly preferred for database primary keys because it avoids the index fragmentation problem that random v4 UUIDs cause in high-write tables.
For most application development in 2026, the practical choice is: v4 for general-purpose unique IDs where ordering does not matter, and v7 for database primary keys or any scenario where insertion order and index efficiency matter.
Step 3: Generate the UUID
The fastest option with no setup is the UUID Generator — it produces a valid UUID instantly in the browser and supports bulk generation if you need several at once for seeding test data.
To generate UUIDs in code:
JavaScript / Node.js (built-in, no library needed):
const id = crypto.randomUUID();
// e.g. "550e8400-e29b-41d4-a716-446655440000"
crypto.randomUUID() is available natively in Node.js 14.17+ and in all modern browsers, and always generates a version 4 UUID using a cryptographically secure random source.
Python (standard library, no installation needed):
import uuid
id = uuid.uuid4()
# e.g. UUID('550e8400-e29b-41d4-a716-446655440000')
uuid.uuid4() is part of Python's standard uuid module. The same module also provides uuid.uuid1() for timestamp/MAC-based UUIDs and uuid.uuid5() for deterministic, name-based UUIDs generated from a namespace and a string using SHA-1 hashing.
For version 7, neither language has a built-in function as of mid-2026 in all runtime versions — use the uuid npm package (uuidv7()) in JavaScript or the uuid7 or uuid-utils packages in Python.
Step 4: Validate an Existing UUID
Before using a UUID received from an external source — an API response, a user-submitted form, or a database import — verify it conforms to the expected format. A valid UUID must satisfy all of the following:
- Exactly 36 characters including hyphens
- Hyphens in the correct positions (8-4-4-4-12 grouping)
- Only hexadecimal characters (0–9, a–f, A–F) in the non-hyphen positions
- A valid version digit (commonly 1, 3, 4, 5, or 7) as the first character of the third group
Use the UUID Validator to check all of these conditions in one step — it flags exactly which rule failed if the string is malformed, which is far faster than manually inspecting the string character by character. Validating format before using a UUID in a database WHERE clause or as a lookup key prevents query errors from malformed input and reduces the attack surface for poorly sanitised inputs.
Step 5: Decide UUID vs Auto-Increment ID
The choice between a UUID and a simple auto-increment integer affects both your application architecture and your database performance:
UUIDs are preferable when:
- Multiple servers or services need to generate IDs independently without coordinating through a shared counter (common in distributed and microservices architectures)
- You want to avoid exposing record count or growth rate through sequential, guessable IDs in public-facing URLs or APIs
- Records may be created offline or merged later from multiple sources without ID collisions
Auto-increment integers are preferable when:
- The system is a single database instance with no distributed-write requirement
- Storage efficiency matters — integers take 4–8 bytes versus 16 bytes for a UUID, which compounds across millions of rows and foreign-key references
- Index performance is critical and you are not using UUID v7 — random v4 UUIDs cause measurable index fragmentation in high-write B-tree-indexed tables
UUID v7 narrows this trade-off significantly by combining the distributed-generation benefit of UUIDs with the sequential-insertion behaviour of auto-increment integers, making it the increasingly preferred default for new database schemas that still want the collision-avoidance properties of a UUID.
Common Mistakes to Avoid
Using UUID v1 for externally-facing IDs. Version 1 UUIDs leak the generating machine's MAC address and exact creation timestamp, which is a real privacy and security exposure if these UUIDs ever appear in a public URL, log file, or API response that an attacker can access.
Using v4 UUIDs as a primary key in high-write databases without considering index cost. Random v4 UUIDs insert at unpredictable positions throughout a B-tree index, causing frequent page splits and fragmentation that degrade write performance at scale. If insertion-order locality matters for your workload, switch to UUID v7 or a similar time-ordered identifier like ULID.
Not validating UUID format before using it in queries. Passing an unvalidated, malformed UUID directly into a database query can cause query errors, and in poorly sanitised code paths, opens the door to injection-style issues. Always validate format — using the UUID Validator or an equivalent check in code — before using external UUID input in a WHERE clause or as a lookup key.
Formula & Methodology
UUID v4 generation works by setting two specific groups of bits to fixed version and variant markers, then filling the remaining 122 bits with cryptographically secure random data:
Total bits: 128
Fixed bits: 6 (4 bits for version = 0100 for v4, 2 bits for variant = 10)
Random bits: 122
Collision probability follows the mathematics of the birthday problem. With 122 bits of randomness (2^122 possible values), the number of UUIDs you would need to generate before a 50% chance of one collision is approximately:
n ≈ 1.42 × √(2^122) ≈ 2.71 × 10^18 (2.71 quintillion)
For context, even a system generating 1 billion UUIDs per second would take over 85 years to reach this threshold — for all practical software engineering purposes, UUID v4 collision risk is treated as zero. UUID v7 carries the same 122-bit-equivalent randomness in its non-timestamp portion, so its collision resistance is comparable, with the added benefit of natural time-based ordering for database insertion efficiency.