UUID Guide — Versions, Use Cases & Best Practices | TextNoteKit

If you're building a modern web application, microservices architecture, or distributed database, you've almost certainly encountered UUIDs. Also known as GUIDs in the Microsoft ecosystem, UUIDs are the industry standard for generating globally unique identifiers without relying on a central database to coordinate.

But did you know there are multiple versions of UUIDs? This guide covers what UUIDs are, how they work, the differences between the various versions (v1, v3, v4, v5), and when you should use them instead of traditional sequential IDs.

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit label used for information in computer systems. The term GUID (Globally Unique Identifier) is used synonymously. The standard is defined by RFC 4122.

The core advantage of a UUID is its uniqueness. You can generate a UUID on any computer, offline, without checking a central database, and guarantee with near-absolute certainty that the ID will never conflict with a UUID generated by anyone else, anywhere, at any time.

UUID Structure and Format

A UUID is typically represented as a 36-character alphanumeric string, containing 32 hexadecimal digits and four hyphens. The standard format looks like this:

123e4567-e89b-12d3-a456-426614174000

This breaks down into five groups of 8-4-4-4-12 characters. Despite looking like just random characters, specific bits within this structure actually identify the UUID version and the variant.

→ Generate UUIDs instantly with our UUID Generator

UUID Versions Explained (v1 vs v3 vs v4 vs v5)

UUIDs are generated using different algorithms depending on their version. Here's a breakdown of the most common ones:

UUID v1: Time & MAC Address

Version 1 UUIDs are generated using the computer's MAC address and the current timestamp (down to 100-nanosecond intervals since October 15, 1582). Because they include a timestamp, they are chronologically sortable.

Drawback: Because they expose the generating computer's MAC address and exact creation time, they are a privacy/security risk and are rarely used in modern public-facing applications.

UUID v3 & v5: Name-based (Deterministic)

Versions 3 and 5 are generated using a "namespace" and a "name". The output is completely deterministic: if you provide the exact same namespace and name, you will always get the exact same UUID.

• v3 uses MD5 hashing (legacy).
• v5 uses SHA-1 hashing (recommended over v3).

Use Case: You want to assign an ID to a specific URL or user email, and you want to be able to recreate that exact ID later just by knowing the email/URL, without storing the ID in a database.

UUID v4: Random

Version 4 is generated purely from random numbers. Out of the 128 bits, 122 bits are randomly generated, and 6 bits are used for version and variant information.

Use Case: Almost everything. This is the standard choice for API keys, database primary keys, session IDs, and general object tracking. Try generating some v4 UUIDs here.

UUIDs vs Sequential IDs (Auto-Increment)

Should you use UUIDs or standard sequential integers (1, 2, 3...) for your database primary keys? There are pros and cons.

UUIDs in Databases (The Fragmentation Problem)

The main drawback of using UUID v4 in databases like PostgreSQL or MySQL is B-tree index fragmentation. Because v4 UUIDs are completely random, inserting them into a clustered index forces the database to constantly rebalance the tree, slowing down write performance.

Solutions:

• Store them efficiently (as `UUID` or `BINARY(16)` types, not as strings).
• Use a time-sorted UUID draft like UUID v7 (currently emerging as a standard) which combines a timestamp with randomness for fast database indexing.
• Use a hybrid approach: an auto-increment integer for the internal Primary Key, and a UUID as a secondary indexed `public_id` exposed to users.

What About UUID Collisions?

A "collision" happens if two randomly generated UUIDs are exactly the same. But the probability is so infinitesimally small that it is functionally zero.

To have a 50% chance of a single collision, you would need to generate 1 billion UUIDs every second for about 85 years. You are astronomically more likely to be struck by lightning while winning the lottery than to ever encounter a UUID v4 collision in your application.

Generating UUIDs in JavaScript

Modern environments provide secure, built-in methods for generating UUIDs without third-party libraries.

// In modern browsers or Node.js >= 14.17.0
const newUuid = crypto.randomUUID();
console.log(newUuid); 
// Output: "36b8f84d-df4e-4d49-b662-bcde71a8764f"

Frequently Asked Questions