Overview
A UUID (Universally Unique Identifier) is a 128-bit value used to identify records, sessions, requests, and resources without a central authority handing out sequential numbers. Every modern programming language and database has built-in or library support for generating them, but picking a UUID version, and deciding whether a UUID beats an auto-increment integer at all, carries real performance and design tradeoffs. This guide covers the format, the version choice, generation in code, validation, and how UUIDs stack up against simpler ID schemes.
The UUID Generator handles instant generation in the browser, and the UUID Validator checks the format of any UUID you receive from elsewhere.
What You Need
- Nothing special for browser-based generation
- For code-based generation, a JavaScript/Node.js, Python, or other runtime with UUID support (most modern languages have this built in or via a standard library)
- A rough sense of what the UUID will identify (a database row, a session token, a distributed request ID) so you can pick the right version
Step 1: Understand the UUID Format
A UUID is a 128-bit value, almost always written as 32 hexadecimal digits arranged in five groups separated by hyphens, in an 8-4-4-4-12 pattern:
550e8400-e29b-41d4-a716-446655440000
The full string always runs 36 characters including the four hyphens. The version shows up 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 bit or two of the fourth group) marks which UUID specification variant is in play, with 8, 9, a, or b as the leading character being the standard RFC variant nearly every modern implementation uses.
Step 2: Choose the Right UUID Version
Several UUID versions exist, but three matter for most work today.
Version 4 (random) comes from 122 bits of randomness, with the remaining 6 bits fixed as version and variant markers. It's the version people reach for most, since it needs no coordination, no machine-specific data, and no timestamp, just a secure random number generator. Use v4 for a simple, general-purpose ID where ordering doesn't matter.
Version 1 (timestamp + MAC address) combines the generating machine's MAC address with a high-precision timestamp. It's fallen out of favor because it leaks machine-identifying information and generation time, a real privacy and security concern once these UUIDs are exposed outside your system.
Version 7 (timestamp-prefixed + random) combines a 48-bit millisecond-precision timestamp with random bits for the rest. That makes v7 UUIDs naturally sortable by creation order, which is why more teams reach for it as a database primary key: it sidesteps the index fragmentation random v4 UUIDs cause in high-write tables.
For most 2026 application development, the practical split is v4 for general-purpose unique IDs where order doesn't matter, and v7 for database primary keys or anywhere insertion order and index efficiency matter.
Step 3: Generate the UUID
The UUID Generator is the fastest option with zero setup. 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 every modern browser, and it always generates a version 4 UUID from 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() lives in Python's standard uuid module. That same module also has uuid.uuid1() for timestamp/MAC-based UUIDs and uuid.uuid5() for deterministic, name-based UUIDs generated from a namespace and a string via SHA-1 hashing.
For version 7, neither language has shipped a built-in function as of mid-2026 across all runtime versions. Reach for 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 that arrived from somewhere else, an API response, a user-submitted form, a database import, check that it matches the expected format. A valid UUID needs to be exactly 36 characters including hyphens, have those hyphens in the right positions (8-4-4-4-12 grouping), use only hexadecimal characters (0 through 9, a through f, A through F) everywhere else, and carry a valid version digit (commonly 1, 3, 4, 5, or 7) as the first character of the third group.
The UUID Validator checks all of this in one pass and flags exactly which rule failed if the string is malformed, much faster than inspecting it character by character. Validating format before dropping a UUID into a database WHERE clause or using it as a lookup key heads off query errors from malformed input and shrinks the attack surface for poorly sanitised inputs.
Step 5: Decide UUID vs Auto-Increment ID
The choice between a UUID and a plain auto-increment integer touches both your application architecture and your database performance.
UUIDs make sense when multiple servers or services need to generate IDs independently without checking in with a shared counter, which is common in distributed and microservices setups. They also help when you don't want sequential, guessable IDs exposing record count or growth rate in public-facing URLs or APIs, or when records might get created offline and merged later from multiple sources without colliding.
Auto-increment integers make sense when you're running a single database instance with no distributed-write requirement. Storage efficiency matters too here: integers run 4 to 8 bytes against 16 for a UUID, and that adds up fast across millions of rows and foreign-key references. Index performance also favors integers unless you're using UUID v7, since random v4 UUIDs cause measurable fragmentation in high-write, B-tree-indexed tables.
UUID v7 closes much of this gap by pairing the distributed-generation benefit of UUIDs with the sequential-insertion behavior of auto-increment integers, which is why it's becoming the default pick for new database schemas that still want a UUID's collision-avoidance properties.
Common Mistakes to Avoid
Using UUID v1 for externally-facing IDs exposes more than people expect. Version 1 UUIDs leak the generating machine's MAC address and exact creation timestamp, a real privacy and security problem if these UUIDs ever land in a public URL, log file, or API response an attacker can reach.
Using v4 UUIDs as a primary key in high-write databases without weighing the index cost causes trouble at scale. Random v4 UUIDs insert at unpredictable positions throughout a B-tree index, triggering frequent page splits and fragmentation that drag down write performance. 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 opens a door you don't need open. Passing an unvalidated, malformed UUID straight into a database query can throw errors, and in poorly sanitised code paths it invites injection-style issues. Validate format first, with 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 sets two specific groups of bits to fixed version and variant markers, then fills 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 math of the birthday problem. With 122 bits of randomness (2^122 possible values), the number of UUIDs you'd need to generate before hitting a 50% chance of one collision comes out to roughly:
n ≈ 1.42 × √(2^122) ≈ 2.71 × 10^18 (2.71 quintillion)
For scale, even a system generating 1 billion UUIDs per second would take over 85 years to reach that threshold. For any practical software engineering purpose, 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 holds up just as well, with the bonus of natural time-based ordering for database insertion efficiency.