How to Generate UUIDs Online

A UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 4122. UUIDs are used to uniquely identify information in distributed systems without requiring central coordination. Unlike auto-incrementing integers, which require a centralized database to generate the next sequential value, UUIDs can be generated independently on any node in a distributed system without any communication or synchronization between nodes. This property makes UUIDs indispensable for modern application architectures that span multiple servers, databases, and geographic regions.

The concept of a universally unique identifier dates back to the 1980s when the Open Software Foundation (OSF) developed the UUID as part of the Distributed Computing Environment (DCE). The specification was later standardized by the Internet Engineering Task Force (IETF) in RFC 4122, published in July 2005. Since then, UUIDs have been adopted across virtually every programming language and platform, with built-in generation functions available in JavaScript, Python, Java, C#, Go, Rust, and many others.

UUID Format

A UUID is typically represented as 32 hexadecimal digits displayed in 5 groups separated by hyphens:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Example: f47ac10b-58cc-4372-a567-0e02b2c3d479

The 32 hexadecimal digits represent 128 bits of data. The format breaks down as follows: the first 8 digits (32 bits) represent the time-related component in time-based UUIDs, followed by a 4-digit group (16 bits), then a 4-digit group (16 bits) that includes the version number, then a 4-digit group (16 bits) that includes the variant, and finally a 12-digit group (48 bits) representing the node or random component.

The version number is embedded in the third group. For example, in the UUID f47ac10b-58cc-4372-a567-0e02b2c3d479, the digit 4 after the third hyphen indicates this is a UUID version 4. The variant is indicated by the most significant bits of the fourth group. The UUID format also supports a canonical representation without hyphens (f47ac10b58cc4372a5670e02b2c3d479), as well as URN notation (urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479).

How UUIDs Are Generated

Different UUID versions use different strategies to generate unique identifiers. Understanding these strategies helps you choose the right version for your application.

UUID v1 (Time-Based)

UUID v1 combines the current timestamp, a clock sequence, and the node's MAC address. The timestamp is a 60-bit count of 100-nanosecond intervals since October 15, 1582 (the date of the Gregorian calendar reform). This gives UUID v1 the property of being monotonically increasing over time, which can be beneficial for database index performance.

However, UUID v1 has privacy implications because the MAC address identifies the specific machine that generated the UUID. An attacker who observes multiple v1 UUIDs can determine the machine's MAC address and potentially track the machine across different contexts. For this reason, UUID v1 is rarely used in public-facing applications unless the MAC address is replaced with a random 48-bit value.

UUID v4 (Random)

UUID v4 generates 122 random bits (6 bits are reserved for the version and variant indicators), yielding approximately 5.3 x 10^36 possible values. This is the most commonly used UUID version because it requires no coordination, no state, and no network access. Any node can generate a v4 UUID at any time with an astronomically low probability of collision.

The randomness in UUID v4 must come from a cryptographically secure random number generator (CSPRNG) to ensure that the outputs are unpredictable. Using a weak random number generator, such as JavaScript's Math.random() in older browsers, can lead to collisions in practice because the internal state of the generator may repeat.

UUID v7 (Time-Ordered)

UUID v7 is a newer version defined in RFC 9562 that combines a Unix timestamp in milliseconds with random bits. The timestamp occupies the most significant bits, making v7 UUIDs monotonically increasing over time. This ordering property dramatically improves database index performance compared to v4, where random ordering causes index fragmentation and page splits in B-tree indexes.

For modern applications, UUID v7 is the recommended choice for database primary keys. It provides the same collision resistance as v4 while offering the database performance characteristics of sequential integers. Major databases like PostgreSQL, MySQL 9+, and SQLite have added native support for UUID v7 generation.

UUID Version Comparison

Version 3 and version 5 are deterministic UUIDs. Given the same namespace and name, they will always produce the same UUID. This is useful when you need a consistent identifier for a resource across different systems without storing the mapping. For example, you could generate a v5 UUID for a user's email address within your application's namespace to create a consistent user identifier across multiple microservices.

UUID v4 Collision Probability

The probability of UUID v4 collisions is often misunderstood. The birthday paradox tells us that collisions become likely once the number of generated UUIDs approaches the square root of the total possible values. For UUID v4, the square root of 2^122 is approximately 2^61, or about 2.3 x 10^18 UUIDs.

To put this in perspective, if you generated 1 billion UUIDs per second, it would take approximately 73 years to reach a 50 percent chance of a single collision. For virtually all practical applications, you can consider UUID v4 collisions to be impossible.

UUID v4 has approximately 5.3 x 10^36 possible values. You would need to generate about 2.7 x 10^18 UUIDs to have a 50% chance of collision.

When to Use UUIDs

Choosing the right UUID version depends on your specific use case and infrastructure.

For distributed database systems where records are created on different servers and merged later, UUIDs eliminate the need for centralized ID generation. UUID v7 is strongly preferred for this use case because its time-ordered nature allows B-tree indexes to maintain good performance as new rows are inserted. PostgreSQL users can use the gen_random_uuid() function for v4 or extensions like pg_uuidv7 for v7 support.

For session identifiers, UUID v4 provides sufficient randomness to prevent session prediction attacks. File names generated with UUID v4 avoid naming conflicts when users upload files with common names like "document.pdf" or "image.jpg." When UUIDs need to appear in URLs, encoding them in Base64 reduces the string length from 36 characters to 22 characters, making URLs more readable.

When NOT to Use UUIDs

While UUIDs are versatile, they are not the right choice for every situation.

• Sequential numbering (use auto-increment). If your application runs on a single database server and does not need to merge data from multiple sources, auto-incrementing integers offer better performance, smaller storage, and simpler debugging.

• Short URLs (use shorter IDs like nanoid). A full UUID string contains 36 characters, which is too long for URL shorteners, referral codes, or any context where brevity matters. Libraries like nanoid generate shorter, URL-safe identifiers using a configurable alphabet and length.

• Human-readable identifiers. UUIDs are not meant to be read, typed, or memorized by humans. For invoice numbers, order IDs, or customer reference codes, use a format that is easier to communicate verbally, such as alphanumeric codes with check digits.

• Tiny datasets (fewer than 100 rows). If your dataset is small enough that auto-incrementing integers would never exhaust their range within your lifetime, there is no benefit to using UUIDs. The additional storage cost (16 bytes for UUID vs 4 bytes for a 32-bit integer) is unnecessary.

Generating UUIDs in Code

While online generators are convenient for one-off use, you will typically generate UUIDs programmatically in your application.

JavaScript (Browser)

const uuid = crypto.randomUUID();
console.log(uuid); // "f47ac10b-58cc-4372-a567-0e02b2c3d479"

Node.js

const { randomUUID } = require('crypto');
const uuid = randomUUID();

Python

import uuid

# Version 4
uuid_v4 = uuid.uuid4()
print(uuid_v4)

# Version 1
uuid_v1 = uuid.uuid1()
print(uuid_v1)

PostgreSQL

-- Version 4
SELECT gen_random_uuid();

-- Version 7 (requires pg_uuidv7 extension)
CREATE EXTENSION IF NOT EXISTS pg_uuidv7;
SELECT uuidv7_generate();

Use the UUID Generator tool to generate various UUID versions online without writing any code.