UUID/GUID Generator

Generate unique identifiers instantly with support for v1, v4, and v5 formats. Create up to 10,000 UUIDs at once with validation, analysis, and multiple export options.

3 UUID Versions
Instant Generation
Validation & Analysis
Database Keys API Tokens Session IDs Distributed Systems
Powered by orbit2x.com

Quick Generate

Generate a UUID instantly with one click

1 100

Tip: Type in the number field for quantities up to 10,000

UUID Validator

Validate and check UUID format, version, and variant

Supports all formats: standard, no-hyphens, braces, URN

Try these examples:

UUID Analyzer

Deep dive into UUID structure, extract timestamps, and view detailed information

Best results with Version 1 UUIDs (time-based)

Try analyzing these:

The Complete Guide to UUID Generation and Implementation

Universally Unique Identifiers (UUIDs) power modern distributed systems, databases, and APIs. Learn how to generate, validate, and implement UUIDs correctly across your infrastructure. Master version selection, understand collision probability, and discover why 125,000+ developers trust our UUID generator monthly.

Understanding UUIDs: The Foundation of Unique Identification

A UUID (Universally Unique Identifier), also called a GUID (Globally Unique Identifier) in Microsoft ecosystems, is a 128-bit label designed to uniquely identify information without requiring central coordination. Think of UUIDs as digital fingerprints—each one is virtually guaranteed to be unique across all space and time. The probability of generating duplicate UUIDs is so astronomically low (1 in 2122 for version 4) that developers treat them as genuinely unique in practical applications.

UUID Structure and Anatomy:

550e8400-e29b-41d4-a716-446655440000
Format: 8-4-4-4-12 hexadecimal digits (32 total)
Total length: 36 characters including hyphens
Bytes: 16 bytes (128 bits) of data
Encoding: Lowercase or uppercase hexadecimal
Segment Breakdown:
  • • Time-low (32 bits): First 8 characters
  • • Time-mid (16 bits): Next 4 characters
  • • Time-high-and-version (16 bits): Next 4 characters
  • • Clock-seq-and-reserved (16 bits): Next 4 characters
  • • Node (48 bits): Final 12 characters
RFC 4122 Compliance:
  • • Standardized by IETF in 2005
  • • Version bits in positions 48-51
  • • Variant bits in positions 64-65
  • • Backward compatible with older systems
  • • Supported across all major programming languages

Why UUIDs Matter in Modern Development:

Traditional sequential IDs (1, 2, 3...) require database coordination and create vulnerabilities. UUIDs eliminate these problems entirely. When you generate a UUID on your laptop, you can be confident it won't collide with one generated simultaneously on a server in Tokyo, a mobile app in London, or an IoT device in SĂŁo Paulo. This property makes UUIDs essential for microservices, offline-first applications, distributed databases, and any system where independent components need to create identifiers without talking to each other first.

340,282,366,920,938,463,463,374,607,431,768,211,456
Possible UUID combinations (2128)
≈ 0%
Collision probability in real-world usage
1 Billion/sec
UUIDs generated before first collision (theoretical)

UUID Versions Explained: Choosing the Right One

Not all UUIDs are created equal. RFC 4122 defines five versions, each designed for specific use cases. Understanding the differences helps you choose the right UUID type for your application's needs—whether prioritizing performance, sortability, determinism, or security.

Version 1

Time-Based UUID (MAC Address + Timestamp)

Version 1 UUIDs embed a timestamp (100-nanosecond intervals since October 15, 1582) and the computer's MAC address. This creates naturally sortable identifiers perfect for time-series data, logs, and event tracking. However, the MAC address inclusion raises privacy concerns in client-facing applications.

✓ Best For:
  • • Database primary keys needing time ordering
  • • Distributed logging systems
  • • Event sourcing and audit trails
  • • Time-series databases (InfluxDB, TimescaleDB)
  • • Systems where creation time matters
✗ Avoid When:
  • • Privacy regulations prohibit MAC disclosure (GDPR)
  • • Client-side generation in public apps
  • • MAC address spoofing is concern
  • • Virtual machines without stable MAC addresses
  • • You need completely random identifiers
Example: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
Contains timestamp from 1997 + network card MAC address
Version 4

Random UUID (Cryptographically Secure)

Version 4 is the gold standard for general-purpose unique identifiers. Using 122 bits of cryptographic randomness, V4 UUIDs reveal nothing about when or where they were created. This version accounts for over 90% of UUID usage in production systems worldwide—and for good reason. It's simple, secure, and requires no coordination or special hardware.

✓ Best For:
  • • API keys and access tokens
  • • Session identifiers
  • • General database primary keys
  • • File and asset unique names
  • • Public-facing identifiers
  • • OAuth state parameters
  • • Message queue correlation IDs
💡 Advantages:
  • • No privacy concerns (pure randomness)
  • • Works offline without coordination
  • • Unpredictable—secure for sensitive contexts
  • • Simple implementation in any language
  • • Industry standard and universally accepted
Example: 550e8400-e29b-41d4-a716-446655440000
Completely random—generated from cryptographic RNG
Version 5

Name-Based UUID (SHA-1 Hashing)

Version 5 UUIDs are deterministic—the same namespace and name always produce the same UUID. This property makes V5 ideal for creating reproducible identifiers from existing data like URLs, email addresses, or domain names. Unlike V4, you can regenerate the exact same UUID given the same inputs, enabling content-based addressing and idempotent systems.

✓ Best For:
  • • URL shorteners (consistent IDs for same URL)
  • • Email-based user identifiers
  • • Content-addressable storage
  • • Deduplication systems
  • • Idempotent API operations
  • • Namespace-based resource identification
⚠️ Considerations:
  • • Same input = same UUID (not random)
  • • Requires namespace selection
  • • SHA-1 collision concerns (theoretical)
  • • Predictable if name is guessable
  • • Not suitable for security-sensitive contexts
Example Input: Namespace: DNS, Name: "example.com"
Generated UUID: cfbff0d1-9375-5685-968c-48ce8b15ae17
Always generates the same UUID for "example.com" in DNS namespace
Nil UUID

Special: All Zeros Placeholder

The Nil UUID (00000000-0000-0000-0000-000000000000) represents an absence of value—like NULL in databases. Use it as a placeholder, default value, or sentinel to indicate "no UUID assigned yet." Particularly useful in optional foreign key relationships or when initializing data structures.

00000000-0000-0000-0000-000000000000
Reserved UUID meaning "empty" or "not set"

Quick Decision Guide:

Need Simple & Secure?
→ Use Version 4
(95% of use cases)
Need Sortable by Time?
→ Use Version 1
(Logs, time-series data)
Need Deterministic?
→ Use Version 5
(Content addressing)

Real-World Applications: Where UUIDs Shine

UUIDs aren't just theoretical—they solve real problems in production systems processing billions of requests daily. From e-commerce giants to fintech startups, here's how organizations leverage UUIDs to build scalable, distributed systems.

Database Primary Keys

Multi-Tenant SaaS Platforms:

Companies like Stripe and Shopify use UUIDs as primary keys across customer databases. When merging data from different shards or regions, UUID primary keys guarantee zero collisions. Traditional auto-increment IDs would clash immediately when combining databases—UUIDs eliminate this entire class of problems.

Example: Customer records from US-East and EU-West databases merge seamlessly without ID conflicts
Distributed Databases (Cassandra, CockroachDB):

UUID primary keys enable horizontal scaling without coordination. Each node generates IDs independently, avoiding bottlenecks from centralized ID generation. Performance stays consistent whether you have 3 nodes or 300.

Offline-First Mobile Apps:

Mobile apps create records offline and sync later. UUIDs prevent duplicate key errors during synchronization. Users create orders, posts, or documents without internet connectivity—UUIDs ensure clean merges when connection restores.

APIs & Microservices

Request/Correlation IDs:

Every API request gets a UUID for tracing through distributed systems. When a user reports an error, engineers search logs using the correlation ID to follow the request's journey across 20+ microservices. Services like Uber and Netflix track millions of requests daily this way.

X-Request-ID: f47ac10b-58cc-4372-a567-0e02b2c3d479
Idempotency Keys:

Payment processors use UUID idempotency keys to prevent duplicate charges. If a network glitch causes the client to retry a payment request, the UUID ensures the charge processes exactly once—critical for financial transactions.

Resource Identifiers:

RESTful APIs expose UUIDs in URLs (api.example.com/orders/550e8400-e29b-...). Unlike sequential IDs, UUIDs don't leak business metrics—competitors can't estimate order volume by watching ID increments.

Security & Authentication

Session Tokens:

Web applications store V4 UUIDs in cookies for session management. The 122 bits of randomness make session hijacking through brute force mathematically infeasible. Auth0 and AWS Cognito both use UUID-based session identifiers.

Password Reset Tokens:

Email verification and password reset links embed time-limited UUIDs. Users click "Forgot Password" and receive a UUID token valid for 15 minutes—secure, unpredictable, and automatically expiring.

example.com/reset/a8098c1a-f86e-11da-bd1a-00112444be1e
OAuth State Parameters:

OAuth 2.0 flows use UUIDs as state tokens preventing CSRF attacks. The authorization server validates the UUID matches before completing authentication—a security best practice required by major OAuth providers.

File Systems & Cloud Storage

Uploaded File Names:

Cloud storage services rename uploaded files to UUIDs preventing collisions and path traversal attacks. When 1000 users upload "invoice.pdf" simultaneously to S3, UUID filenames ensure each gets unique storage without overwrites.

/uploads/2024/01/f81d4fae-7dec-11d0-a765-00a0c91e6bf6.pdf
Content-Addressable Storage:

Git and IPFS use UUID-like hashes for versioning. Each file version gets a unique identifier based on content. CDNs leverage this pattern for cache invalidation—new content always gets a new UUID.

Asset Management Systems:

Digital asset managers track images, videos, and documents with UUIDs. Marketing teams reference assets by UUID across campaigns, ensuring the correct version loads even after file renames or moves.

Industry-Specific UUID Applications

💳 E-Commerce & Retail
  • • Order IDs: Track purchases across payment gateways, warehouses, and shipping
  • • Cart Sessions: Persist shopping carts across devices and days
  • • Inventory SKUs: Manage products in distributed warehouse systems
  • • Coupon Codes: Generate unique, non-sequential promotional codes
  • • Wishlist Items: Allow offline wishlist creation before user login
🏥 Healthcare & Medical
  • • Patient Records: HIPAA-compliant identifiers replacing SSNs
  • • Lab Results: Track specimens across multiple facilities
  • • Prescription IDs: Ensure medication orders never duplicate
  • • Medical Devices: IoT device identification in hospitals
  • • Appointment Scheduling: Coordinate across multi-location practices
🎮 Gaming & Entertainment
  • • Player IDs: Unique identifiers across game servers worldwide
  • • Match Sessions: Track multiplayer game instances
  • • In-Game Items: NFT-style ownership of unique digital assets
  • • Achievement Unlocks: Record progress in cloud save systems
  • • Tournament Brackets: Manage competitive gaming events

Message Queues & Event Streaming

Apache Kafka, RabbitMQ, and AWS SQS rely heavily on UUIDs for message identification. Each message gets a UUID allowing systems to detect duplicate processing, maintain exactly-once semantics, and debug message flow issues. When microservices communicate asynchronously, UUID message IDs become the single source of truth for tracking events through complex workflows.

Real-world scenario: An order confirmation triggers 15 downstream events (inventory update, shipping notification, analytics tracking, recommendation engine update, etc.). The original order UUID propagates through all messages, enabling complete end-to-end tracing from initial purchase through fulfillment.

Implementation Patterns & Database Optimization

Database Indexing Strategies

⚠️ Common Pitfall: B-Tree Index Fragmentation

Random UUIDs (V4) cause B-tree index fragmentation in traditional SQL databases. Each insert lands in a random position, forcing page splits and degrading write performance over time. MySQL and PostgreSQL experience 30-50% slower inserts with UUID primary keys compared to sequential IDs on large tables.

Impact: A table with 100M records might see INSERT performance drop from 10,000 ops/sec to 5,000 ops/sec
✓ Solutions
  • • PostgreSQL: Use UUID with hash indexes instead of B-tree for non-sequential lookups
  • • MySQL 8.0+: Store UUIDs as BINARY(16) for better index efficiency
  • • Use UUIDv1 for time-series: Sortable nature reduces fragmentation
  • • Hybrid approach: Auto-increment internal ID + UUID for public API
  • • Partition tables: Range partition by UUID prefix reduces index size
Storage Optimization Tips:
PostgreSQL: Use UUID column type (16 bytes) not TEXT (37 bytes)
MySQL: BINARY(16) with UUID_TO_BIN() and BIN_TO_UUID()
MongoDB: Native UUID support with BinData subtype 4
Cassandra: uuid or timeuuid column types

Performance Benchmarks

Generation Speed (Operations/Second)
UUIDv4 (Random): ~10M ops/sec
UUIDv1 (Time-based): ~8M ops/sec
UUIDv5 (SHA-1): ~2M ops/sec
Benchmarked on modern server CPU (Intel Xeon/AMD EPYC). V4 is fastest due to pure randomness without hashing overhead.
Storage Requirements
Text Format (ASCII): 36-45 bytes
Depends on format: standard (36), braces (38), URN (45)
Binary Format: 16 bytes
Native UUID type in PostgreSQL, MySQL, MongoDB
Savings at Scale: 56% smaller
1B records: 36GB (text) vs 16GB (binary) = 20GB saved
Memory & Network Impact

Transmitting UUIDs in APIs adds bandwidth cost. Consider: 1M API responses with 5 UUIDs each = 180MB extra data transfer (text) vs 80MB (binary). For high-traffic APIs, binary encoding in payloads significantly reduces costs and latency.

Language-Specific Implementation Notes

Recommended Libraries
JavaScript/Node.js: uuid package (50M downloads/week)
Python: uuid module (built-in standard library)
Java: java.util.UUID (built-in since Java 5)
Go: github.com/google/uuid (Google's implementation)
PHP: ramsey/uuid or built-in functions (PHP 8.3+)
Ruby: SecureRandom.uuid (built-in)
C#/.NET: System.Guid (framework built-in)
Rust: uuid crate (zero-cost abstraction)
Common Mistakes to Avoid
✗ Don't: Generate UUIDs client-side for security tokens
Use crypto.randomUUID() or server-side generation for session tokens
✗ Don't: Use Math.random() for UUID generation
Not cryptographically secure—use proper UUID libraries
✗ Don't: Store UUIDs as VARCHAR(36) when binary available
Wastes 20 extra bytes per record + slower indexes
✗ Don't: Use UUIDv1 in privacy-sensitive applications
Exposes MAC address—GDPR compliance issue
✗ Don't: Expose database internal IDs in APIs
Use UUIDs publicly, keep auto-increment IDs internal

Security Considerations: When UUIDs Protect (and When They Don't)

UUIDs provide unpredictability, not encryption. Understanding this distinction prevents security vulnerabilities while leveraging UUIDs' inherent randomness for appropriate use cases.

✓ Security Benefits UUIDs Provide

Enumeration Attack Prevention

Sequential IDs leak business intelligence. Attackers iterate through /api/users/1, /api/users/2, /api/users/3 discovering all users. UUID endpoints (/api/users/f47ac10b-...) make enumeration computationally infeasible—guessing a valid UUID would require trying 2122 combinations.

Real attack prevented: E-commerce sites using sequential order IDs revealed daily sales volume to competitors monitoring ID increments. UUID order IDs eliminated this intelligence leak entirely.
Unpredictable Resource Identifiers

Password reset tokens, email verification links, and temporary access URLs need unpredictability. UUIDv4 provides 122 bits of entropy—equivalent to a 21-character fully random alphanumeric string. Attackers cannot predict the next token even after observing millions of previous tokens.

https://app.com/reset/a8098c1a-f86e-11da-bd1a-00112444be1e
CSRF State Token Generation

OAuth 2.0 and OpenID Connect mandate unpredictable state parameters preventing cross-site request forgery. UUIDv4 perfectly fits this requirement—cryptographically random, stateless generation, no coordination needed between authorization server and client.

Privacy-Preserving Identifiers

Healthcare apps use UUIDs instead of Social Security Numbers for patient identification. Financial apps replace account numbers with UUIDs in logs and analytics. If leaked, UUIDs reveal nothing about the underlying identity—unlike sequential IDs that indicate signup order or account creation patterns.

✗ What UUIDs Don't Provide

Not Access Control

Critical mistake: Assuming UUID URLs are "secret enough" for authorization. Even with UUIDs, always validate permissions server-side. Just because /api/documents/f47ac10b-... is hard to guess doesn't mean an attacker won't obtain it through phishing, logs, or network interception.

Always required: Check if requesting user has permission to access the resource identified by UUID. Unguessability ≠ Authorization.
Not Encryption or Authentication

UUIDs are identifiers, not cryptographic keys. Don't use UUIDs as encryption keys, signing secrets, or authentication credentials. They lack sufficient entropy for cryptographic purposes and are designed for identification, not confidentiality.

Use instead: Dedicated crypto libraries (crypto.randomBytes, secrets.token_urlsafe) for security tokens requiring stronger guarantees than identification needs.
Version 1 Privacy Concerns

UUIDv1 embeds MAC addresses—potentially GDPR violations if personally identifiable. European regulators consider persistent hardware identifiers personal data. Server logs containing V1 UUIDs might inadvertently store user MAC addresses, creating compliance issues.

GDPR-compliant alternative: Use UUIDv4 for user-facing identifiers or generate V1 UUIDs with randomized node fields instead of real MAC addresses.
Time-Limited Security

UUIDs alone don't expire. Password reset links using only UUIDs remain valid until manually invalidated. Always pair UUIDs with expiration timestamps, rate limiting, and one-time-use flags for security-critical operations.

Cryptographic Quality Randomness

Entropy Sources for UUIDv4

Reputable UUID libraries use operating system cryptographic random number generators (CSPRNGs). These sources gather entropy from hardware events, timing variations, and specialized random number generators, providing unpredictable output suitable for security applications.

Linux: /dev/urandom (kernel CSPRNG)
Windows: BCryptGenRandom (CNG API)
macOS: arc4random (kernel entropy pool)
Browser: crypto.getRandomValues() (Web Crypto API)
Entropy Calculation

UUIDv4 contains 122 bits of randomness (128 bits total minus 4 version bits and 2 variant bits). This provides security equivalent to a 21-character password using all alphanumeric characters plus symbols.

Possible combinations: 5.3 × 1036
Brute force attempts (1B/sec): 168 trillion years
Birthday paradox collision: 2.71 × 1018 UUIDs

Collision Probability: The Math Behind UUID Uniqueness

"Will my UUIDs ever collide?" This question comes up constantly. Here's the mathematical reality explained without requiring a statistics degree.

Birthday Paradox Applied to UUIDs

The birthday paradox states that in a room of just 23 people, there's a 50% chance two share a birthday. This seems counterintuitive since there are 365 days—surely you'd need more people? The math works because we're checking all possible pairs, not one specific match.

23 people
50% chance of shared birthday
(365 possible days)
2.71 × 1018
UUIDs for 50% collision chance
(2122 possible UUIDs)
2.7 quintillion
That's 2,710,000,000,000,000,000 UUIDs
(2.71 billion billions)

Translation: If every human on Earth generated 1 billion UUIDs per second for 100 years, we'd still be nowhere near collision territory.

Real-World Collision Scenarios

Generating 1 billion UUIDs/second
Time until 50% collision chance: 85 years
Scale: Entire internet traffic × 1000
1 trillion UUIDs stored globally
Collision probability: 0.000000018%
1012 records across all systems worldwide
Typical enterprise database (10 million records)
Collision probability: 0.00000000001%
Effectively impossible—hardware failure more likely
Microservice generating 1 UUID/request
At 1000 req/sec for 10 years: Zero risk
~315 billion UUIDs—nowhere near danger zone

Comparative Risk Analysis

Being struck by lightning (lifetime)
Probability: 1 in 15,300
Winning lottery jackpot (single ticket)
Probability: 1 in 300 million
Asteroid impact extinction event
Probability: 1 in 75 million
UUID collision (1 trillion UUIDs)
Probability: 1 in 5.5 trillion

Bottom line: You're 73,000 times more likely to win the lottery jackpot than experience a UUID collision in a database with 1 trillion records. In practice, treat UUID collisions as impossible—worry about hardware failures, software bugs, and human errors instead.

The Formula (For Math Enthusiasts)

Collision probability follows the birthday paradox formula. For n random UUIDs from a space of N possible values:

P(collision) ≈ 1 - e(-n² / 2N)
Where N = 2122 for UUIDv4 (122 random bits)
For 50% collision probability:
n ≈ 1.2 × √N = 2.71 × 1018 UUIDs
For 1% collision probability:
n ≈ 0.38 × √N = 8.06 × 1017 UUIDs

Migrating from Sequential IDs to UUIDs

Transitioning existing systems from auto-increment integers to UUIDs requires planning. Here are battle-tested strategies minimizing downtime and data integrity risks.

Recommended: Phased Dual-Key Approach

Phase 1: Add UUID Column

Add a nullable UUID column alongside existing integer primary key. Generate UUIDs for all existing records. This phase has zero breaking changes—existing code continues working.

ALTER TABLE users ADD COLUMN uuid BINARY(16);
Phase 2: Expose UUIDs in API

Update API responses to include both ID types. New integrations use UUIDs; legacy clients continue using integer IDs. Support both in API endpoints during transition period.

{"id": 12345, "uuid": "f47ac10b-..."}
Phase 3: Migrate Foreign Keys

Create UUID-based foreign keys alongside integer FKs. Gradually migrate relationships table by table. Test thoroughly before dropping integer references.

Phase 4: Deprecate Integer IDs

After migration period (typically 6-12 months), mark integer ID endpoints as deprecated. Provide migration timeline to API consumers. Eventually remove integer IDs when usage drops to zero.

Alternative Migration Strategies

Hybrid Approach: Keep Both Permanently

Maintain integer IDs for internal joins and UUID for external APIs. Best of both worlds—fast integer joins internally, UUID security externally. Many large companies use this pattern permanently.

✓ Pros: No performance degradation, backward compatible, minimal risk
✗ Cons: Increased storage, more complex queries, two sources of truth
Big Bang Migration (High Risk)

Replace all integer IDs with UUIDs in single migration. Requires extensive downtime, complete test coverage, and rollback plan. Only viable for small databases or during scheduled maintenance windows.

✓ Pros: Clean cutover, no hybrid complexity
✗ Cons: Significant downtime, high rollback risk, breaks all existing integrations
New Tables Only Approach

Use UUIDs for all new tables, leave legacy tables unchanged. Microservices architecture fits this well—new services use UUIDs while monolith retains integers. Eventually decommission legacy systems.

✓ Pros: Zero migration risk, gradual transition
✗ Cons: Inconsistent identifier strategy, cross-table relationships complex
⚠️ Critical Consideration

Before migrating, benchmark UUID query performance on production-scale data. Index fragmentation with random UUIDs can significantly impact write-heavy workloads. Test thoroughly before committing to full migration.

Pre-Migration Checklist

Technical Preparation
  • ☐ Benchmark UUID vs integer performance on production hardware
  • ☐ Calculate storage increase (16 bytes vs 4-8 bytes per record)
  • ☐ Test index performance with UUID primary keys
  • ☐ Verify UUID library support in all application languages
  • ☐ Plan foreign key migration strategy for related tables
  • ☐ Update ORM models and database schemas
  • ☐ Create data migration scripts with rollback capability
Business/API Preparation
  • ☐ Communicate changes to API consumers with timeline
  • ☐ Version API endpoints (v1 integers, v2 UUIDs)
  • ☐ Update API documentation and SDKs
  • ☐ Maintain backward compatibility period (6-12 months)
  • ☐ Monitor API traffic by ID type during transition
  • ☐ Plan deprecation timeline for integer ID endpoints
  • ☐ Train support staff on new identifier format