UUID Guide: Versions, Formats, and When to Use Each

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bitvalue designed to be globally unique without requiring a central authority to issue or coordinate identifiers. UUIDs allow distributed systems, independent applications, and disconnected devices to generate identifiers that will never collide — even if millions are created per second across the globe.

The concept was originally developed by Apollo Computer for the Network Computing System and later standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE). Today, UUIDs are defined in RFC 9562 (which superseded the original RFC 4122) and are used in virtually every programming language, database system, and distributed architecture in production.

A UUID is represented as a 32-character hexadecimal string divided into five groups separated by hyphens, following the canonical 8-4-4-4-12 format:

// UUID 표준 형식 (8-4-4-4-12)
550e8400-e29b-41d4-a716-446655440000
│        │    │    │    │
│        │    │    │    └─ 노드 (12자)
│        │    │    └─ 클럭 시퀀스 + 변형 비트 (4자)
│        │    └─ 버전 비트 + 상위 시간 (4자)
│        └─ 중간 시간 (4자)
└─ 하위 시간 (8자)

With 2¹²⁸ possible values (approximately 3.4 × 10³⁸), the UUID space is so vast that the probability of generating a duplicate is negligibly small for any practical application. This mathematical guarantee of uniqueness is what makes UUIDs the universal standard for distributed identification.

UUID Format Breakdown

Every UUID consists of exactly 32 hexadecimal characters(0–9, a–f) and 4 hyphens, totaling 36 characters in its string representation. While the hyphens are purely cosmetic — they carry no data — they are part of the canonical format defined in the RFC and are expected by most parsers and validators.

Beneath the surface, the 128 bits encode specific metadata depending on the UUID version. Two critical fields are present in every UUID regardless of version:

Version Bits

The 13th hexadecimal character (the first character of the third group) indicates the UUID version. For example, a UUID beginning with xxxxxxxx-xxxx-4xxx is a version 4 UUID. The version field occupies bits 48–51 (4 bits) and tells the consumer how the remaining bits should be interpreted.

Variant Bits

The 17th hexadecimal character (the first character of the fourth group) encodes the variant, which specifies the UUID layout. For RFC-compliant UUIDs, this character will always be one of 8, 9, a, or b (the two most significant bits are 10 in binary). This is known as the RFC 4122 / RFC 9562 variant.

// UUID 구조 식별 예시
550e8400-e29b-41d4-a716-446655440000
                   ^         ^
                   │         └─ 변형 비트: 'a' → 이진수 1010 → 상위 2비트 '10' = RFC 변형
                   └─ 버전 비트: '4' → UUID v4

// 다른 버전 예시
6ba7b810-9dad-11d1-80b4-00c04fd430c8  → 버전 '1', 변형 '8' → UUID v1
01929d6c-7e00-7cc3-98d7-6c8b2345f0ab  → 버전 '7', 변형 '9' → UUID v7

UUID Versions Explained

The UUID specification defines several versions, each using a different strategy to achieve uniqueness. The version determines what information is embedded in the UUID and how it is generated. Here is a comprehensive comparison of the most important versions:

UUID v1: Timestamp + MAC Address

Version 1 UUIDs combine a 60-bit timestamp (measured in 100-nanosecond intervals since October 15, 1582) with the 48-bit MAC address of the generating machine. A 14-bit clock sequence handles cases where the clock is set backwards or the node ID changes. While v1 guarantees uniqueness through hardware identity, it has a significant privacy concern: the embedded MAC address reveals the physical network interface of the machine that generated the UUID. This makes v1 unsuitable for public-facing identifiers and is the primary reason it has fallen out of favor.

UUID v3 & v5: Namespace-Based Hashing

Versions 3 and 5 are deterministic: given the same namespace UUID and name string, they always produce the same output. Version 3 uses MD5 as its hashing algorithm, while version 5 uses SHA-1. The RFC defines four standard namespaces — DNS, URL, OID, and X.500 — but you can use any UUID as a custom namespace.

// 네임스페이스 기반 UUID 생성 예시
// 동일한 입력 → 항상 동일한 UUID 출력

// v5 (SHA-1): DNS 네임스페이스 + "example.com"
Namespace: 6ba7b810-9dad-11d1-80b4-00c04fd430c8 (DNS)
Name:      "example.com"
Result:    cfbff0d1-9375-5685-968c-48ce8b15ae17

// v3 (MD5): URL 네임스페이스 + "https://example.com"
Namespace: 6ba7b811-9dad-11d1-80b4-00c04fd430c8 (URL)
Name:      "https://example.com"
Result:    074e5e44-8e9a-3220-8bd4-16ec37896040

Because v3 relies on MD5, which has known collision vulnerabilities, v5 is recommendedfor all new applications requiring name-based UUIDs. The deterministic nature of these versions makes them ideal for generating stable identifiers from known inputs — for example, mapping a URL to a consistent UUID for deduplication.

UUID v4: The Most Popular Version

UUID v4 is by far the most widely used version in modern software. Its design is elegantly simple: of the 128 total bits, 6 bits are reserved for the version (4 bits) and variant (2 bits) fields, leaving 122 bits of pure randomness generated by a cryptographically secure random number generator (CSRNG).

This means there are 2¹²² possible v4 UUIDs — approximately 5.3 × 10³⁶ unique values. To put this in perspective: if you generated 1 billion UUIDs every second, it would take approximately 170 trillion years to exhaust the space. The probability of a single collision after generating 103 trillion v4 UUIDs is only one in a billion.

Birthday Paradox and Collision Probability

The realistic collision probability follows the birthday paradox formula. For n generated UUIDs in a space of N = 2¹²² possible values, the probability P of at least one collision is approximately:

// 충돌 확률 근사 공식 (생일 문제)
P(collision) ≈ 1 - e^(-n² / (2 × N))

// 실제 수치 예시:
// n = 1,000,000 (백만 개)       → P ≈ 1.09 × 10⁻²⁵  (사실상 0)
// n = 1,000,000,000 (10억 개)   → P ≈ 1.09 × 10⁻¹⁹  (사실상 0)
// n = 2.71 × 10¹⁸ (26경 개)    → P ≈ 50%

// 결론: 실용적인 규모에서 UUID v4 충돌은 걱정할 필요가 없다

Generating UUID v4 in Code

Modern platforms provide native support for UUID v4 generation. In JavaScript (browser and Node.js), the crypto.randomUUID() method generates a cryptographically secure v4 UUID with a single function call:

// JavaScript / TypeScript — UUID v4 생성
const uuid = crypto.randomUUID();
// 결과: "3b241101-e2bb-4d7a-8702-9e0de8b1fc13"

// Python — uuid 표준 라이브러리
import uuid
my_uuid = uuid.uuid4()
# 결과: UUID('a3bb189e-8bf9-3888-9912-ace4e6543002')

// Java — java.util.UUID
UUID uuid = UUID.randomUUID();
// 결과: 38400000-8cf0-11bd-b23e-10b96e4ef00d

// Go — google/uuid 패키지
import "github.com/google/uuid"
id := uuid.New()
// 결과: 6ba7b810-9dad-11d1-80b4-00c04fd430c8

The key advantage of crypto.randomUUID() over older approaches (like Math.random()-based implementations) is that it uses the operating system's cryptographic random number generator, ensuring the output is unpredictable and suitable for security-sensitive contexts. You can generate UUIDs instantly using our UUID Generator tool.

UUID v7: The New Standard for Databases

UUID v7 is the newest addition to the UUID family, introduced in RFC 9562 (2024). It was designed specifically to address the biggest weakness of UUID v4 in database contexts: random UUIDs fragment B-tree indexes. Because v4 values are uniformly distributed, each new insert lands at a random position in the index, causing excessive page splits, increased write amplification, and degraded read performance over time.

UUID v7 solves this by embedding a 48-bit Unix timestamp in milliseconds in the most significant bits, followed by 74 bits of randomness (after reserving 6 bits for version and variant). This means v7 UUIDs are naturally time-ordered: UUIDs generated later will always sort after UUIDs generated earlier when compared lexicographically.

// UUID v7 구조 (128비트)
┌──────────────────────────────────────────────────┐
│ 48비트 Unix 타임스탬프 (ms) │ 4비트 버전 ('7')   │
├──────────────────────────────────────────────────┤
│ 12비트 랜덤(a)  │ 2비트 변형 │ 62비트 랜덤(b)    │
└──────────────────────────────────────────────────┘

// 시간순 정렬 예시 — 생성 순서대로 자동 정렬
01929d6c-7e00-7cc3-98d7-6c8b2345f0ab  (2024-12-01T10:00:00Z)
01929d6c-9a40-7f12-a1b2-3c4d5e6f7890  (2024-12-01T10:00:01Z)
01929d6d-b680-7aa1-b3c4-d5e6f7890123  (2024-12-01T10:00:02Z)
↑ 앞쪽 비트가 시간값이므로, 문자열 정렬 = 시간순 정렬

UUID v4 vs v7 Comparison

The tradeoff is clear: v7 sacrifices some randomness to gain time-ordering, which dramatically improves database write and read performance. For most applications that store UUIDs in a database, v7 is the better choice. If you need maximum unpredictability and have no database indexing concerns, v4 remains ideal.

GUID vs UUID

If you come from the Microsoft ecosystem, you have likely seen the term GUID (Globally Unique Identifier) used interchangeably with UUID. This is because GUIDs and UUIDs are functionally identical— they refer to the same 128-bit identifier following the same format. The difference is purely historical and terminological.

Microsoft adopted the DCE UUID specification early on and coined the term "GUID" for their implementation in COM, .NET, and SQL Server. The Windows API function CoCreateGuid() and the .NET type System.Guid both generate standard RFC-compliant UUIDs. There are a few minor differences in convention:

In practice, the byte order difference only matters when you are comparing the binary representation across platforms. At the string level, a UUID and a GUID are interchangeable. When someone says "GUID," they almost certainly mean a standard UUID.

When to Use UUIDs

UUIDs shine in scenarios where identifiers must be generated independently without coordination. Here are the most common use cases:

Distributed Systems & Microservices

In a microservices architecture, multiple services often need to create records simultaneously without communicating with a central ID server. UUIDs allow each service to generate identifiers independently while guaranteeing no collisions. This eliminates a single point of failure and removes inter-service dependencies during record creation.

Database Primary Keys

Using UUIDs as primary keys enables data to be generated on the client side before it reaches the database, simplifies data merging across shards or replicas, and eliminates the need for auto-increment sequences that can become bottlenecks. With UUID v7, the index fragmentation issue is resolved, making this approach practical even for write-heavy workloads. Consider pairing UUID generation with our Random Number Generator for additional entropy in custom implementations.

API Resource Identifiers

Exposing sequential integer IDs in a REST API leaks information: attackers can enumerate resources, estimate your user count, and predict future IDs. UUIDs reveal nothing about ordering or volume. An API endpoint like /api/users/550e8400-e29b-41d4-a716-446655440000 is far more secure than /api/users/42.

Session Tokens & Temporary Identifiers

UUIDs (specifically v4) are commonly used for session identifiers, CSRF tokens, file upload references, and other temporary values that must be unique and unpredictable. The 122 bits of randomness in a v4 UUID provide sufficient entropy to resist brute-force guessing attacks. For even stronger security, consider using our Hash Generator to create HMAC-based tokens.

UUID Anti-patterns

While UUIDs are incredibly useful, they are not always the right choice. Here are common mistakes developers make when adopting UUIDs:

Replacing Sequential IDs Without Considering the Tradeoffs

A UUID stored as a string takes 36 bytes, while stored as binary it occupies 16 bytes — compared to just 4 bytes for a 32-bit integer or 8 bytes for a 64-bit integer. For a table with hundreds of millions of rows, this difference in primary key size cascades through every index, foreign key reference, and join operation. Before replacing auto-increment IDs with UUIDs, ensure the benefits (distributed generation, merge safety) outweigh the storage and performance costs.

Using UUID v4 as a Clustered Index Key

This is the single most common UUID anti-pattern. Random v4 UUIDs cause severe B-tree fragmentation when used as a clustered (primary) index in databases like MySQL InnoDB or SQL Server. Each insert lands at a random leaf page, causing constant page splits and dramatically increasing write latency. Use UUID v7 instead— its time-ordered nature ensures sequential inserts that append to the end of the index.

Exposing UUIDs in User-Facing URLs Without Purpose

URLs like /invoice/550e8400-e29b-41d4-a716-446655440000 are long, ugly, and hard for users to share or remember. If the resource does not need the security properties of a UUID, consider using a shorter identifier like a NanoID or a human-readable slug. Reserve UUIDs for internal identifiers and API references where aesthetics do not matter.

Not Storing UUIDs in Binary Format

Storing UUIDs as VARCHAR(36) wastes more than twice the space compared to a native BINARY(16) or UUID column type. PostgreSQL has a native uuid type that stores values as 16 bytes internally. MySQL 8.0+ offers UUID_TO_BIN() and BIN_TO_UUID() functions for efficient binary storage. Always use the most compact representation your database supports.

Generate UUIDs with BeautiCode

Whether you need a single UUID for testing or a bulk batch for database seeding, the BeautiCode UUID Generator has you covered. It runs entirely in your browser — no data is sent to any server, and your generated UUIDs are never stored or logged.

• Instant generation— generate single or bulk UUIDs with one click
• Multiple versions— choose v4 (random) or other versions based on your needs
• Copy-friendly output— click to copy, or download as a text file for batch use
• 100% client-side— all generation happens in your browser using the Web Crypto API

Try it now: BeautiCode UUID Generator

Frequently Asked Questions

Can two UUID v4 values ever be the same?

Theoretically yes, but practically no. With 2¹²²possible values, the probability of a collision is astronomically low. You would need to generate approximately 2.71 × 10¹⁸ UUIDs (2.71 quintillion) before reaching a 50% chance of a single duplicate. For context, that is more than 600 million UUIDs per second for 136 years straight.

Should I use UUID v4 or v7 for my database?

If your database uses B-tree indexes (which most do), UUID v7 is the better choice. Its time-ordered nature prevents index fragmentation and delivers significantly better write performance. Use v4 only when you need maximum randomness and do not care about sort order — for example, in session tokens or API keys.

Is a UUID the same as a GUID?

Yes, for all practical purposes. GUID is Microsoft's name for the same 128-bit identifier defined by the UUID specification. The only minor differences are cosmetic (Microsoft often uses uppercase and curly braces) and a mixed-endian byte order in the binary representation. At the string level, they are fully interchangeable.

Can I extract a timestamp from a UUID?

It depends on the version. UUID v1 and v7 both embed timestamps and can be decoded to extract the creation time. UUID v7 is particularly straightforward: the first 48 bits are a standard Unix timestamp in milliseconds. UUID v4, being purely random, contains no temporal information whatsoever.

How should I store UUIDs in a database?

Use a native UUID type when available (e.g., PostgreSQL's uuid type). If your database does not have a native type, store UUIDs as BINARY(16) rather than VARCHAR(36). This halves storage requirements and improves index performance. For MySQL, use the built-in UUID_TO_BIN() function with the swap flag for v1 UUIDs to improve sort order.