A UUID (Universally Unique Identifier) is a 128-bit identifier designed to be unique across all devices and time without requiring central coordination. UUIDs are formatted as 32 hexadecimal digits in 5 groups separated by hyphens (8-4-4-4-12): e.g., 550e8400-e29b-41d4-a716-446655440000. They are defined by RFC 4122 and used in databases, distributed systems, APIs, and software to uniquely identify records, sessions, and resources.

What is the difference between UUID versions?

UUID v1 uses timestamp and MAC address (can reveal device info). UUID v4 is fully random (most common, privacy-friendly). UUID v3/v5 are namespace-based using MD5/SHA-1 hashing for deterministic IDs. UUID v6 reorders v1 fields for better sorting. UUID v7 uses Unix timestamp + random bits for time-ordered, database-optimized IDs. For most applications, use v4 for simplicity or v7 for database primary keys.

Can UUIDs collide or duplicate?

UUID collisions are theoretically possible but astronomically unlikely. UUID v4 has 122 random bits, providing 5.3×10^36 possible values. To have a 50% probability of collision, you would need to generate 2.71 quintillion UUIDs—more than the grains of sand on Earth. In practice, you would run out of storage space before generating a duplicate. For all practical purposes, treat UUIDs as unique.

Should I use UUID for database primary keys?

UUIDs can be excellent primary keys, especially in distributed systems. Advantages: no coordination needed between servers, merge-friendly, prevents enumeration attacks, works offline. Disadvantages: 16 bytes vs 4-8 for integers (more storage/memory), random UUIDs (v4) fragment B-tree indexes causing slower inserts. Solution: use UUID v7 (time-ordered) or store as binary(16) instead of varchar(36).

What is the difference between UUID and GUID?

GUID (Globally Unique Identifier) and UUID (Universally Unique Identifier) are the same thing—just different names. Microsoft coined 'GUID' in the 1990s for COM/Windows, while the industry standard uses 'UUID' per RFC 4122. Both follow identical specifications and formats. Use whichever term your platform prefers: GUID in .NET/Windows, UUID everywhere else.

When should I use UUID v7 instead of v4?

Use UUID v7 when IDs will be used as database primary keys or need to be sortable by creation time. UUID v7 embeds a Unix timestamp in the first 48 bits, making IDs naturally chronological. This dramatically improves database insert performance (no B-tree fragmentation) and allows rough time-based queries. Use v4 when you need maximum randomness or have privacy concerns about revealing creation time.

How do I generate UUIDs in different programming languages?

JavaScript: crypto.randomUUID() or uuid package. Python: import uuid; uuid.uuid4(). Java: UUID.randomUUID(). C#/.NET: Guid.NewGuid(). PHP: Ramsey\Uuid\Uuid::uuid4(). Go: github.com/google/uuid. Ruby: SecureRandom.uuid. All produce RFC 4122 compliant v4 UUIDs. For v7, use dedicated libraries as native support is still limited.

UUID vs ULID vs nanoid: which should I use?

UUID: universal standard, wide support, 36 characters. ULID: sortable, URL-safe, 26 characters, Crockford Base32. nanoid: shortest (21 chars default), URL-safe, customizable alphabet, fastest generation. Choose UUID for interoperability and standards compliance. Choose ULID for sortable IDs with better readability. Choose nanoid for compact URL-safe IDs in modern web apps.

Are UUIDs secure and safe for authentication tokens?

UUID v4 provides 122 bits of randomness—sufficient for most use cases but not ideal for security tokens. For authentication tokens, session IDs, or API keys, prefer cryptographically secure random bytes (256+ bits) using crypto.getRandomValues() or similar. UUIDs are predictable in v1 (timestamp-based) and have less entropy than purpose-built token generators.

How should I store UUIDs in a database?

Best practice: store as BINARY(16) or native UUID type (PostgreSQL). This uses 16 bytes vs 36 for varchar, improves index performance, and reduces storage by 55%. If using varchar(36), always use lowercase with hyphens for consistency. PostgreSQL has a native UUID type. MySQL 8+ has UUID_TO_BIN()/BIN_TO_UUID() functions. For maximum compatibility, use varchar(36) with proper indexing.

Back

UUID Generator

A UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 4122, formatted as 32 hexadecimal digits in 5 groups (8-4-4-4-12): xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M digit indicates version (1, 4, 5, 7), N indicates variant. UUID v4 uses 122 random bits with collision probability of 1 in 5.3×10^36. UUIDs enable distributed ID generation without coordination—essential for microservices, databases, and offline-capable apps.

Generate UUIDs v1, v4, and v7 online. Create random UUIDs, time-based UUIDs, or time-ordered UUIDs for databases. Bulk generate up to 100 UUIDs with optional formatting (uppercase, no dashes). Copy to clipboard instantly.

Options

Count

Version

UppercaseNo dashes

How to Use

Enter your value in the input field
Click the Calculate/Convert button
Copy the result to your clipboard

Frequently Asked Questions

What is a UUID?: A UUID (Universally Unique Identifier) is a 128-bit identifier designed to be unique across all devices and time without requiring central coordination. UUIDs are formatted as 32 hexadecimal digits in 5 groups separated by hyphens (8-4-4-4-12): e.g., 550e8400-e29b-41d4-a716-446655440000. They are defined by RFC 4122 and used in databases, distributed systems, APIs, and software to uniquely identify records, sessions, and resources.
What is the difference between UUID versions?: UUID v1 uses timestamp and MAC address (can reveal device info). UUID v4 is fully random (most common, privacy-friendly). UUID v3/v5 are namespace-based using MD5/SHA-1 hashing for deterministic IDs. UUID v6 reorders v1 fields for better sorting. UUID v7 uses Unix timestamp + random bits for time-ordered, database-optimized IDs. For most applications, use v4 for simplicity or v7 for database primary keys.
Can UUIDs collide or duplicate?: UUID collisions are theoretically possible but astronomically unlikely. UUID v4 has 122 random bits, providing 5.3×10^36 possible values. To have a 50% probability of collision, you would need to generate 2.71 quintillion UUIDs—more than the grains of sand on Earth. In practice, you would run out of storage space before generating a duplicate. For all practical purposes, treat UUIDs as unique.
Should I use UUID for database primary keys?: UUIDs can be excellent primary keys, especially in distributed systems. Advantages: no coordination needed between servers, merge-friendly, prevents enumeration attacks, works offline. Disadvantages: 16 bytes vs 4-8 for integers (more storage/memory), random UUIDs (v4) fragment B-tree indexes causing slower inserts. Solution: use UUID v7 (time-ordered) or store as binary(16) instead of varchar(36).
What is the difference between UUID and GUID?: GUID (Globally Unique Identifier) and UUID (Universally Unique Identifier) are the same thing—just different names. Microsoft coined 'GUID' in the 1990s for COM/Windows, while the industry standard uses 'UUID' per RFC 4122. Both follow identical specifications and formats. Use whichever term your platform prefers: GUID in .NET/Windows, UUID everywhere else.
When should I use UUID v7 instead of v4?: Use UUID v7 when IDs will be used as database primary keys or need to be sortable by creation time. UUID v7 embeds a Unix timestamp in the first 48 bits, making IDs naturally chronological. This dramatically improves database insert performance (no B-tree fragmentation) and allows rough time-based queries. Use v4 when you need maximum randomness or have privacy concerns about revealing creation time.
How do I generate UUIDs in different programming languages?: JavaScript: crypto.randomUUID() or uuid package. Python: import uuid; uuid.uuid4(). Java: UUID.randomUUID(). C#/.NET: Guid.NewGuid(). PHP: Ramsey\Uuid\Uuid::uuid4(). Go: github.com/google/uuid. Ruby: SecureRandom.uuid. All produce RFC 4122 compliant v4 UUIDs. For v7, use dedicated libraries as native support is still limited.
UUID vs ULID vs nanoid: which should I use?: UUID: universal standard, wide support, 36 characters. ULID: sortable, URL-safe, 26 characters, Crockford Base32. nanoid: shortest (21 chars default), URL-safe, customizable alphabet, fastest generation. Choose UUID for interoperability and standards compliance. Choose ULID for sortable IDs with better readability. Choose nanoid for compact URL-safe IDs in modern web apps.
Are UUIDs secure and safe for authentication tokens?: UUID v4 provides 122 bits of randomness—sufficient for most use cases but not ideal for security tokens. For authentication tokens, session IDs, or API keys, prefer cryptographically secure random bytes (256+ bits) using crypto.getRandomValues() or similar. UUIDs are predictable in v1 (timestamp-based) and have less entropy than purpose-built token generators.
How should I store UUIDs in a database?: Best practice: store as BINARY(16) or native UUID type (PostgreSQL). This uses 16 bytes vs 36 for varchar, improves index performance, and reduces storage by 55%. If using varchar(36), always use lowercase with hyphens for consistency. PostgreSQL has a native UUID type. MySQL 8+ has UUID_TO_BIN()/BIN_TO_UUID() functions. For maximum compatibility, use varchar(36) with proper indexing.

Complete Guide

What is a UUID/GUID?

A UUID (Universally Unique Identifier) is a 128-bit identifier designed to be unique across all devices and time without requiring a central coordinating authority. First standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE) in the 1990s, UUIDs have become fundamental to modern software development.

Microsoft adopted the concept as GUIDs (Globally Unique Identifiers) for COM and Windows development. Despite the different names, UUID and GUID refer to the same standard defined by RFC 4122. The terms are completely interchangeable—use "GUID" in Microsoft/.NET contexts and "UUID" everywhere else.

UUIDs solve a critical problem in distributed systems: how do you generate a unique identifier when multiple computers, servers, or devices need to create IDs simultaneously without communicating with each other? Traditional auto-incrementing database IDs require a central authority (the database) to coordinate. UUIDs eliminate this bottleneck.

UUID Structure Explained

A UUID consists of 128 bits (16 bytes) typically represented as 32 hexadecimal digits in five groups separated by hyphens: 8-4-4-4-12 format.

Example: 550e8400-e29b-41d4-a716-446655440000

Breaking down the structure: • 550e8400 (time_low): 32 bits for timestamp or random data • e29b (time_mid): 16 bits for timestamp or random data • 41d4 (time_hi_and_version): 4 bits for version + 12 bits data. The "4" indicates version 4 • a716 (clock_seq_hi_variant + clock_seq_low): 2-3 bits for variant + 13-14 bits data. The "a" (binary 1010) indicates RFC 4122 variant • 446655440000 (node): 48 bits for node identifier or random data

The version digit (position 13, the "M" in xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx) tells you how the UUID was generated. The variant digit (position 17, "N") indicates the UUID layout standard.

UUID Versions: When to Use Each

UUID v1 (Time-based): Generated from timestamp and MAC address. Pros: Contains creation time, guaranteed unique per machine. Cons: Reveals MAC address (privacy concern), not suitable for security-sensitive applications. Use for: Legacy systems, when creation time matters.

UUID v3 (Name-based, MD5): Generated by hashing a namespace UUID + name with MD5. Same inputs always produce the same UUID. Use for: Creating deterministic IDs from meaningful data (e.g., user email → user ID).

UUID v4 (Random): 122 bits of cryptographically random data. Most common version. Pros: Simple, private, no coordination needed. Cons: Completely random—fragments database indexes. Use for: General purpose, when you just need a unique ID.

UUID v5 (Name-based, SHA-1): Like v3 but uses SHA-1 instead of MD5. Preferred over v3 for new applications due to stronger hash.

UUID v6 (Reordered Time-based): Rearranges v1 timestamp fields for better sorting. Draft standard. Use for: When you need v1 features but with chronological ordering.

UUID v7 (Unix Timestamp + Random): Newest version (RFC 9562). Combines Unix millisecond timestamp with random bits. Pros: Time-sortable, database-friendly, no MAC address exposure. This is the recommended version for database primary keys.

Code Examples

Here's how to generate UUIDs in popular programming languages:

// JavaScript (Node.js or Browser)
import { v4 as uuidv4, v7 as uuidv7 } from 'uuid';
const id = uuidv4();  // Random UUID
const timeId = uuidv7();  // Time-ordered UUID

// Native (modern browsers/Node 19+)
const id = crypto.randomUUID();

# Python
import uuid
id = uuid.uuid4()  # Random UUID
id = uuid.uuid1()  # Time-based UUID

// Java
import java.util.UUID;
UUID id = UUID.randomUUID();  // Random UUID

// C# / .NET
Guid id = Guid.NewGuid();

// Go
import "github.com/google/uuid"
id := uuid.New()  // Random UUID

// PHP (using ramsey/uuid)
use Ramsey\Uuid\Uuid;
$id = Uuid::uuid4();

-- PostgreSQL (native support)
SELECT gen_random_uuid();
SELECT uuid_generate_v4();

UUIDs in Databases: Best Practices

Storage Format: Store UUIDs as BINARY(16) or native UUID type, not VARCHAR(36). Binary storage uses 16 bytes vs 36 for string representation—a 55% reduction that significantly impacts index size and query performance.

PostgreSQL: Has native UUID type. Use gen_random_uuid() or uuid-ossp extension.

MySQL: Use BINARY(16) with UUID_TO_BIN(uuid, 1) and BIN_TO_UUID(uuid, 1). The second parameter swaps bytes for time-based UUIDs to improve index locality.

Index Fragmentation: Random UUIDs (v4) cause B-tree index fragmentation because new values scatter across the index. Solutions: 1. Use UUID v7 (time-ordered)—new UUIDs append to index end 2. Use ULID or similar time-sortable format 3. Use composite key with timestamp prefix

Primary Key Considerations: • Pros: No coordination between servers, merge-friendly, prevents ID enumeration attacks • Cons: Larger than integers, random inserts fragment indexes, harder to debug/communicate • Recommendation: Use UUID v7 for new projects needing distributed ID generation

UUID Alternatives Compared

ULID (Universally Unique Lexicographically Sortable Identifier): 26 characters, Crockford Base32 encoded. 48-bit timestamp + 80-bit random. Sortable by creation time, URL-safe, case-insensitive. Good choice when you want sortability and shorter IDs.

KSUID (K-Sortable Unique Identifier): 27 characters, Base62 encoded. 32-bit timestamp + 128-bit random. Created by Segment.io. Sortable, includes Unix timestamp, larger random component than ULID.

nanoid: Customizable length (default 21 characters), URL-safe alphabet. Smaller and faster than UUID. No built-in timestamp. Best for: compact IDs in URLs, when you control the entire system.

Snowflake IDs: 64-bit integers with timestamp + datacenter + machine + sequence. Used by Twitter, Discord. Sortable, compact, but requires coordination for machine IDs.

CUID2: Secure, collision-resistant, horizontally scalable. Modern replacement for the original CUID. Good for security-sensitive applications.

Choose UUID when you need maximum interoperability and standards compliance. Choose alternatives when you have specific requirements (shorter IDs, sortability, or system control).

UUID Versions Comparison

Version	Generation Method	Best For	Sortable
UUID v1	Timestamp + MAC address	Legacy systems	Partially
UUID v3	MD5 hash of namespace + name	Deterministic IDs	No
UUID v4	122 random bits	General purpose	No
UUID v5	SHA-1 hash of namespace + name	Deterministic IDs	No
UUID v6	Reordered v1 timestamp	Database keys	Yes
UUID v7	Unix timestamp + random	Database keys (recommended)	Yes

UUID vs Alternative ID Formats

Format	Length	Sortable	URL-Safe	Use Case
UUID v4	36 chars	No	Yes*	Universal standard
UUID v7	36 chars	Yes	Yes*	Database primary keys
ULID	26 chars	Yes	Yes	Sortable, compact
KSUID	27 chars	Yes	Yes	K-sortable, includes timestamp
nanoid	21 chars	No	Yes	Compact, fast, customizable
Snowflake	18-19 digits	Yes	Yes	Twitter-style, datacenter IDs

UUID Structure (8-4-4-4-12 Format)

Section	Bits	Example	Purpose
time_low	32	550e8400	Timestamp (low)
time_mid	16	e29b	Timestamp (mid)
time_hi_version	16	41d4	Version + timestamp (high)
clock_seq_hi_variant	8	a7	Variant + clock sequence
clock_seq_low	8	16	Clock sequence (low)
node	48	446655440000	Node ID / random