UUID Generator

UUID Generator - Create UUID v4 / v1 Online

Generate universally unique identifiers instantly

Create UUIDs (Universally Unique Identifiers) online for free. Generate random UUID v4, time-based UUID v1, or nil UUIDs with customizable formatting options. Perfect for developers needing database primary keys, API request IDs, or distributed system identifiers. Fast, secure, and runs entirely in your browser with no data storage.

Generate UUIDs (Tool)

Use our UUID generator to create universally unique identifiers with customizable options.

Generator Options

UUID Version:

• UUID v4 (Random) - Cryptographically random 128-bit identifier (most common)
• UUID v1 (Time-based) - Timestamp + node-based identifier
• Nil UUID - All-zero UUID placeholder (00000000-0000-0000-0000-000000000000)

Number of UUIDs:

• Generate 1 to 100 UUIDs at once
• Bulk generation for batch processing
• Each UUID is unique (collision probability ~ 0)

Formatting Options:

• Uppercase - Display hexadecimal characters as A-F instead of a-f
• Remove Dashes - Output as continuous 32-character hexadecimal string

Output Format Examples

Standard UUID v4 (default):

550e8400-e29b-41d4-a716-446655440000

Uppercase UUID v4:

550E8400-E29B-41D4-A716-446655440000

UUID without dashes (32 characters):

550e8400e29b41d4a716446655440000

UUID v1 (time-based):

6ba7b810-9dad-11d1-80b4-00c04fd430c8

Nil UUID:

00000000-0000-0000-0000-000000000000

How to Use

1. Select UUID version (v4 recommended for most uses)
2. Choose quantity (1-100 UUIDs)
3. Set formatting options (uppercase/remove dashes if needed)
4. Click "Generate" to create UUIDs instantly
5. Copy results for use in your application

Quick Features

Instant generation - Create UUIDs in milliseconds Batch support - Generate up to 100 UUIDs at once Cryptographically secure - Uses browser's CSPRNG for v4 Flexible formatting - Uppercase, no dashes, standard format Multiple versions - v1, v4, and nil UUID support Privacy-first - All processing happens locally in your browser No installation - Works immediately, no downloads required

What Is a UUID (and GUID)?

A UUID (Universally Unique Identifier) is a 128-bit identifier used to uniquely label information in computer systems without requiring a central coordination authority.

UUID Basics

Definition: UUIDs are standardized by RFC 4122 (original specification) and RFC 9562 (updated specification). They provide a way to generate identifiers that are:

• Globally unique across space and time
• Decentralized - no central registry needed
• Collision-resistant - extremely low probability of duplicates

Format: A UUID is 128 bits (16 bytes) typically represented as 32 hexadecimal digits displayed in five groups separated by hyphens:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Where:

• x = hexadecimal digit (0-9, a-f)
• M = UUID version (e.g., 4 for random)
• N = variant (typically 8, 9, a, or b)

Example:

550e8400-e29b-41d4-a716-446655440000
    
                             
8 chars  4 chars 4 chars 4 chars 12 chars

UUID vs. GUID

Are they the same? Yes, essentially. UUID and GUID (Globally Unique Identifier) refer to the same concept:

UUID (Universally Unique Identifier):

• Standard term used in IETF specifications
• Used in Unix/Linux, Java, Python, web standards
• Defined by RFC 4122 and RFC 9562

GUID (Globally Unique Identifier):

• Microsoft's term for the same identifier
• Common in Windows, .NET, COM/DCOM
• Follows the same RFC 4122 standard

Practical difference: The terminology differs by platform, but the underlying 128-bit identifier format and generation methods are identical. A UUID generated on Linux is compatible with GUID-expecting systems on Windows.

Why Use UUIDs?

Decentralized generation: Create unique identifiers without coordinating with a central authority or database sequence. Multiple systems can generate UUIDs simultaneously without conflicts.

Distributed systems: Perfect for microservices, cloud applications, and databases where coordination would create bottlenecks.

Merge-friendly: Records created independently with UUIDs can be merged without ID conflicts, unlike auto-incrementing integers.

Opaque identifiers: UUIDs don't reveal information about the number of records, creation order, or timing (especially v4), enhancing privacy.

UUID Format Explained (Hyphens, Length, Hex)

Understanding UUID structure helps you work with them effectively across different systems.

Standard Format: 8-4-4-4-12

The canonical textual representation:

550e8400-e29b-41d4-a716-446655440000
                          
    
8 chars  4ch  4ch  4ch  12 chars

Total length:

• 36 characters with hyphens (32 hex digits + 4 hyphens)
• 32 characters without hyphens (pure hexadecimal)

Hexadecimal digits: Each position can be 0-9 or a-f (or A-F in uppercase):

• Lowercase: 550e8400-e29b-41d4-a716-446655440000
• Uppercase: 550E8400-E29B-41D4-A716-446655440000

Both are valid and represent the same UUID. Case-insensitivity is part of the standard.

Version and Variant Fields

Version field (13th character): Indicates the UUID generation method:

550e8400-e29b-41d4-a716-446655440000
             
          version

Common versions:

• 1 = Time-based (v1)
• 4 = Random (v4)
• 7 = Unix timestamp-based (v7, newer)

Variant field (17th character): Specifies the UUID variant (typically RFC 4122):

550e8400-e29b-41d4-a716-446655440000
                 
              variant

RFC 4122 variant uses values: 8, 9, a, or b (binary: 10xx)

Why Remove Dashes?

Some systems require UUIDs without hyphens:

With dashes (36 chars):

550e8400-e29b-41d4-a716-446655440000

Without dashes (32 chars):

550e8400e29b41d4a716446655440000

Use cases for dash-free format:

• URL slugs or query parameters (cleaner, no encoding needed)
• Database columns with fixed 32-character length
• Systems that don't recognize the hyphenated format
• Filename generation
• Hash-like representations

Same value, different presentation: Both formats represent identical UUIDs. The hyphens are purely for human readability - they're not part of the actual data.

Alternative Representations

URN format:

urn:uuid:550e8400-e29b-41d4-a716-446655440000

Microsoft GUID format (with braces):

{550e8400-e29b-41d4-a716-446655440000}

Binary (128 bits): UUIDs are ultimately 16 bytes of binary data. The hexadecimal text representation is for human convenience.

UUID Versions (Which One Should I Use?)

Different UUID versions serve different purposes. Choose based on your requirements.

UUID v4 (Random) - Recommended for Most Uses

How it works: Version 4 UUIDs are generated using cryptographically secure random numbers. The 128 bits consist of:

• 122 bits of randomness
• 6 bits for version and variant fields

Example:

f47ac10b-58cc-4372-a567-0e02b2c3d479
                      
          version 4  variant

Advantages:

• Simple - Just generate random bits
• No coordination - Completely independent generation
• Privacy-preserving - No embedded metadata
• Most common - Widely supported and understood
• Secure randomness - Uses cryptographic RNG

Disadvantages:

• Not sortable - Random order, poor for database indexes
• No timestamp - Can't extract creation time
• Slightly higher collision risk - Still negligible (see FAQ)

When to use UUID v4:

• Database primary keys (non-time-sensitive)
• API request/correlation IDs
• Session identifiers (non-secret)
• File and object naming
• Distributed systems without shared state
• General-purpose unique identifiers

Best for: Most applications where you just need a unique ID without special requirements.

UUID v1 (Time-based)

How it works: Version 1 UUIDs encode:

• Timestamp - 60 bits from Gregorian calendar epoch (1582-10-15)
• Clock sequence - 14 bits to handle backward clock adjustments
• Node ID - 48 bits, typically MAC address

Example:

6ba7b810-9dad-11d1-80b4-00c04fd430c8
                      
          version 1  variant

Advantages:

• Sortable by time - Natural ordering by creation timestamp
• Extractable timestamp - Can determine when UUID was created
• High uniqueness - Combines time, node, and sequence

Disadvantages:

• Privacy concern - May expose MAC address (hardware identifier)
• Complexity - Requires clock synchronization
• Metadata leakage - Reveals timing and potentially machine identity
• Coordination needed - Clock sequence management

Privacy note: If the node ID uses a real MAC address, v1 UUIDs can be traced back to specific hardware. Some implementations use random node IDs to mitigate this.

When to use UUID v1:

• When you need temporal ordering
• Database systems benefiting from time-based indexing
• Scenarios where timestamp extraction is valuable
• Internal systems where privacy isn't a concern

When NOT to use UUID v1:

• Public-facing identifiers (privacy risk)
• Systems without reliable clocks
• When you want to avoid metadata leakage

Modern alternative: UUID v7 (see below) provides time-ordering with better privacy.

Nil UUID (All Zeros)

Format:

00000000-0000-0000-0000-000000000000

What it represents: The nil UUID is a special UUID with all 128 bits set to zero. It represents "no UUID" or "null UUID."

When to use nil UUID:

• Default/placeholder value - Before a real UUID is assigned
• Null checks - Testing whether a UUID field is populated
• Invalid state - Signaling that no valid identifier exists
• Protocol compliance - Some APIs expect UUIDs but allow nil for "none"

Example use case:

let currentUser = getNilUUID(); // Default to nil
if (userAuthenticated()) {
  currentUser = generateUUID(); // Assign real UUID
}

Comparison: Most programming languages provide easy nil UUID checks:

if user_id == uuid.UUID('00000000-0000-0000-0000-000000000000'):
    # No user assigned

UUID v7 (Time-Ordered) - Modern Alternative

Note: Not yet generated by this tool, but worth understanding for future use.

How it works: UUID v7 (defined in RFC 9562, 2024) combines:

• Unix timestamp (milliseconds) - First 48 bits
• Random data - Remaining bits for uniqueness

Example:

017F22E2-79B0-7CC3-98C4-DC0C0C07398F
             
          version 7

Advantages over v1:

• Better privacy - No MAC address exposure
• Sortable - Natural timestamp ordering
• Simpler - Uses standard Unix time
• Database-friendly - Excellent for B-tree indexes

Advantages over v4:

• Time-ordered - Natural chronological sorting
• Better index performance - Sequential writes to B-tree indexes
• Timestamp extractable - Can determine creation time

When to use UUID v7:

• Modern applications needing time-ordered IDs
• Database primary keys (better than v4 for indexes)
• Distributed systems with timestamp requirements
• Replacement for Snowflake IDs or ULIDs

Adoption status: UUID v7 is specified in RFC 9562 (2024) but not yet universally supported in all languages and frameworks. Expect broader adoption in coming years.

Common Use Cases

UUIDs serve critical roles across software development and system architecture.

1. Database Primary Keys

Why UUIDs for database IDs:

Advantages:

• Merge-friendly - Combine databases without ID conflicts
• Decentralized - Generate IDs application-side, not in database
• No sequence coordination - Multiple writers don't contend for sequences
• Opaque - Don't reveal record counts or creation order

Example (SQL):

CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  username VARCHAR(50),
  created_at TIMESTAMP
);

INSERT INTO users (username) 
VALUES ('alice');
-- ID automatically generated: 550e8400-e29b-41d4-a716-446655440000

Considerations:

• Storage: 16 bytes vs. 4-8 bytes for integers
• Index performance: v4 random UUIDs can cause index fragmentation (v7 better)
• Display: Longer and less human-friendly than integers

Best practice: Use UUID v7 or ULID for new projects to get sortability benefits.

2. API Request IDs and Trace IDs

Distributed system tracking:

UUIDs uniquely identify requests across services, enabling:

• Correlation - Link related operations across microservices
• Debugging - Trace request path through system
• Logging - Aggregate logs by request ID

Example (HTTP header):

X-Request-ID: 123e4567-e89b-12d3-a456-426614174000

Logging example:

[123e4567-e89b-12d3-a456-426614174000] User login initiated
[123e4567-e89b-12d3-a456-426614174000] Auth service called
[123e4567-e89b-12d3-a456-426614174000] Token generated
[123e4567-e89b-12d3-a456-426614174000] Login successful

Benefits:

• Unique across all services and time
• No coordination needed between services
• Easy to search logs and traces

3. File and Object Naming

Unique filenames without conflicts:

Upload handling:

// Generate unique filename
const uuid = crypto.randomUUID();
const filename = \`\${uuid}.jpg\`;
// Result: 550e8400-e29b-41d4-a716-446655440000.jpg

Benefits:

• No overwrites - Each file has unique name
• No enumeration - Can't guess other filenames
• Scalable - Works across multiple servers

Use cases:

• User uploads (profile pictures, documents)
• Temporary files
• Cache keys
• Object storage (S3, Azure Blob)

4. Session and Transaction Identifiers

Track user sessions and transactions:

Session ID example:

const sessionId = crypto.randomUUID();
// Store in cookie or token: 7c9e6679-7425-40de-944b-e07fc1f90ae7

Transaction ID example:

transaction_id = uuid.uuid4()
# Use for payment processing: a1b2c3d4-e5f6-47g8-h9i0-j1k2l3m4n5o6

Important: UUIDs are identifiers, not security tokens. Don't use them as:

• Password reset tokens (use cryptographic tokens)
• Authentication secrets (use proper session management)
• Authorization capabilities (use signed tokens like JWTs)

5. Message Queue and Event IDs

Event-driven architecture:

UUIDs uniquely identify messages and events:

{
  "eventId": "550e8400-e29b-41d4-a716-446655440000",
  "eventType": "OrderPlaced",
  "timestamp": "2024-02-10T12:00:00Z",
  "data": { ... }
}

Benefits:

• Idempotency - Detect duplicate message processing
• Tracing - Track event flow through system
• Deduplication - Identify already-processed events

6. Resource Identifiers in REST APIs

RESTful resource URLs:

GET /api/users/550e8400-e29b-41d4-a716-446655440000
PUT /api/orders/7c9e6679-7425-40de-944b-e07fc1f90ae7
DELETE /api/posts/a1b2c3d4-e5f6-47g8-h9i0-j1k2l3m4n5o6

Advantages:

• Non-enumerable - Can't iterate through IDs to access all resources
• Future-proof - No need to migrate if you exceed integer ranges
• Mergeable - Combine data from multiple sources without conflicts

Developer Snippets

Generate UUIDs programmatically in popular languages using built-in functions.

JavaScript / TypeScript

Modern browsers (recommended):

// Generate UUID v4 (most common)
const uuid = crypto.randomUUID();
console.log(uuid);
// Output: "550e8400-e29b-41d4-a716-446655440000"

// Generate multiple UUIDs
const uuids = Array.from({ length: 10 }, () => crypto.randomUUID());

Browser support:

• Chrome 92+
• Firefox 95+
• Safari 15.4+
• Edge 92+

Node.js (v14.17.0+):

const crypto = require('crypto');

// Generate UUID v4
const uuid = crypto.randomUUID();
console.log(uuid);

Older environments (using crypto.getRandomValues):

function generateUUID() {
  return ([1e7]+-1e3+-4e3+-8e3+-1e11).replace(/[018]/g, c =>
    (c ^ crypto.getRandomValues(new Uint8Array(1))[0] & 15 >> c / 4).toString(16)
  );
}

const uuid = generateUUID();

Using npm uuid package:

import { v4 as uuidv4, v1 as uuidv1 } from 'uuid';

// UUID v4 (random)
const id1 = uuidv4();
// Output: "550e8400-e29b-41d4-a716-446655440000"

// UUID v1 (timestamp-based)
const id2 = uuidv1();
// Output: "6ba7b810-9dad-11d1-80b4-00c04fd430c8"

// UUID without dashes
const id3 = uuidv4().replace(/-/g, '');
// Output: "550e8400e29b41d4a716446655440000"

Python

Using uuid module:

import uuid

# UUID v4 (random)
id1 = uuid.uuid4()
print(id1)
# Output: 550e8400-e29b-41d4-a716-446655440000

# UUID v1 (timestamp-based)
id2 = uuid.uuid1()
print(id2)
# Output: 6ba7b810-9dad-11d1-80b4-00c04fd430c8

# Nil UUID
nil = uuid.UUID('00000000-0000-0000-0000-000000000000')
# Or: nil = uuid.UUID(int=0)

# Convert to string
uuid_str = str(id1)

# Uppercase
uuid_upper = str(id1).upper()

# Without dashes
uuid_no_dash = str(id1).replace('-', '')
# Or: uuid_no_dash = id1.hex

# Generate multiple
uuids = [uuid.uuid4() for _ in range(10)]

Working with UUID objects:

# Create from string
my_uuid = uuid.UUID('550e8400-e29b-41d4-a716-446655440000')

# Get as bytes
uuid_bytes = my_uuid.bytes  # 16 bytes

# Get as integer
uuid_int = my_uuid.int  # 128-bit integer

# Get version
print(my_uuid.version)  # 4

# Check if nil
if my_uuid == uuid.UUID(int=0):
    print("Nil UUID")

Java

Using java.util.UUID:

import java.util.UUID;

// Generate UUID v4 (random)
UUID uuid = UUID.randomUUID();
System.out.println(uuid);
// Output: 550e8400-e29b-41d4-a716-446655440000

// Convert to string
String uuidStr = uuid.toString();

// Uppercase
String uuidUpper = uuid.toString().toUpperCase();

// Without dashes
String uuidNoDash = uuid.toString().replace("-", "");

// Generate multiple
List<UUID> uuids = IntStream.range(0, 10)
    .mapToObj(i -> UUID.randomUUID())
    .collect(Collectors.toList());

Create from string:

// Parse UUID from string
UUID parsed = UUID.fromString("550e8400-e29b-41d4-a716-446655440000");

// Create nil UUID
UUID nil = new UUID(0L, 0L);

// Compare UUIDs
if (uuid1.equals(uuid2)) {
    System.out.println("Same UUID");
}

UUID properties:

UUID uuid = UUID.randomUUID();

// Get version
int version = uuid.version();  // 4

// Get variant
int variant = uuid.variant();  // 2 (RFC 4122)

// Most/least significant bits
long msb = uuid.getMostSignificantBits();
long lsb = uuid.getLeastSignificantBits();

Note: Java's UUID.randomUUID() uses SecureRandom, providing cryptographically strong random values.

C# / .NET

Using System.Guid:

using System;

// Generate GUID (UUID v4)
Guid guid = Guid.NewGuid();
Console.WriteLine(guid);
// Output: 550e8400-e29b-41d4-a716-446655440000

// Convert to string
string guidStr = guid.ToString();

// Uppercase
string guidUpper = guid.ToString().ToUpper();

// Without dashes (N format)
string guidNoDash = guid.ToString("N");
// Output: 550e8400e29b41d4a716446655440000

// With braces (B format)
string guidBraces = guid.ToString("B");
// Output: {550e8400-e29b-41d4-a716-446655440000}

Parse from string:

// Parse GUID
Guid parsed = Guid.Parse("550e8400-e29b-41d4-a716-446655440000");

// TryParse (safer)
if (Guid.TryParse(input, out Guid result)) {
    Console.WriteLine(
quot;Valid GUID: {result}");
}

// Empty GUID (nil UUID)
Guid empty = Guid.Empty;
// Output: 00000000-0000-0000-0000-000000000000

PHP

Using native functions:

// Generate UUID v4 (PHP 7.0+)
function guidv4() {
    $data = random_bytes(16);
    $data[6] = chr(ord($data[6]) & 0x0f | 0x40); // Version 4
    $data[8] = chr(ord($data[8]) & 0x3f | 0x80); // Variant
    return vsprintf('%s%s-%s-%s-%s-%s%s%s', str_split(bin2hex($data), 4));
}

$uuid = guidv4();
echo $uuid;
// Output: 550e8400-e29b-41d4-a716-446655440000

// Uppercase
$uuid_upper = strtoupper($uuid);

// Without dashes
$uuid_no_dash = str_replace('-', '', $uuid);

Security & Best Practices

Understanding UUID security properties helps you use them appropriately.

UUIDs Are NOT Security Tokens

Critical distinction:

UUIDs ARE:

• Unique identifiers
• Hard to guess (v4)
• Suitable for non-secret references

UUIDs ARE NOT:

• Secret credentials
• Authorization capabilities
• Cryptographic keys
• Password reset tokens (by themselves)

Why this matters:

UUID v4 entropy: While v4 UUIDs have 122 bits of randomness (very large space), they're not designed as security tokens. The RFC 4122 spec explicitly states:

"Do not assume that UUIDs are hard to guess; they should not be used as security capabilities."

Use cases to avoid:

Bad: Using UUID as password reset token

// DON'T DO THIS
const resetToken = crypto.randomUUID();
sendEmail(\`Reset: /reset?token=\${resetToken}\`);

Bad: Using UUID as API authentication secret

// DON'T DO THIS
const apiKey = crypto.randomUUID(); // Too short, not cryptographic

Bad: Using UUID for session management without additional security

// INSECURE
sessionId = crypto.randomUUID(); // No expiry, no signing

Proper alternatives:

Good: Cryptographic tokens for sensitive operations

// Use crypto.getRandomValues for secure tokens
const tokenBytes = new Uint8Array(32);
crypto.getRandomValues(tokenBytes);
const resetToken = btoa(String.fromCharCode(...tokenBytes));

Good: UUIDs as identifiers WITH proper security layers

// UUID identifies the resource
const resourceId = crypto.randomUUID();

// But access requires authentication + authorization
if (user.isAuthenticated() && user.canAccess(resourceId)) {
  return getResource(resourceId);
}

When UUIDs Are Secure Enough

Appropriate security-adjacent uses:

Request/correlation IDs - Identifying requests without being secret Resource identifiers - When combined with proper auth Session IDs - When signed and validated server-side Non-enumerable URLs - Preventing casual URL guessing

Example: Secure session usage

// UUID identifies session
const sessionId = crypto.randomUUID();

// But security comes from:
// 1. Server-side validation
// 2. HTTPS only
// 3. Proper expiration
// 4. HttpOnly cookies
// 5. CSRF protection

UUID v4 Collision Probability

How likely are collisions?

UUID v4 has 122 bits of randomness:

• Total possible UUIDs: ~5.3 x 1036
• Probability of collision is extremely low

Birthday paradox calculation:

To have a 50% chance of collision:

• Need ~2.7 x 1018 UUIDs (2.7 quintillion)
• Generating 1 billion UUIDs/second: would take 86 years

To have a 0.0000001% chance (essentially zero):

• Can safely generate trillions of UUIDs

Practical takeaway: Collisions are theoretically possible but practically negligible. You're more likely to have hardware failures or software bugs than UUID collisions.

Privacy Considerations

UUID v1 privacy risk:

UUID v1 can expose:

• MAC address - Hardware identifier
• Timestamp - When UUID was created
• Clock sequence - Hints about system state

Example vulnerability: If a company generates v1 UUIDs for customer records, attackers could:

1. Extract MAC addresses (identify servers)
2. Determine record creation times (activity patterns)
3. Correlate UUIDs across databases

Mitigation:

• Use UUID v4 for public-facing identifiers
• Use UUID v7 for sortable IDs without MAC address exposure
• If using v1, ensure node ID is random, not actual MAC

Best Practices Summary

Do:

• Use UUID v4 for general unique identifiers
• Use UUIDs for database primary keys (consider v7 for better index performance)
• Generate UUIDs with cryptographically secure RNGs (crypto.randomUUID(), SecureRandom, etc.)
• Combine UUIDs with proper authentication/authorization
• Use consistent formatting within your system

Don't:

• Treat UUIDs as secrets or security capabilities
• Use UUIDs alone for password reset or authentication
• Expose UUID v1 in public APIs (privacy risk)
• Assume zero collision probability (have database unique constraints)
• Use weak random number generators for UUID creation

Troubleshooting

Common issues and solutions when working with UUIDs.

"Why did I get uppercase/lowercase output?"

Cause: Different formatting preferences across systems.

Understanding:

• UUIDs are case-insensitive: 550E8400... = 550e8400...
• The standard allows either case
• Different tools default to different cases

Solutions:

JavaScript:

// Lowercase (browser default)
const lower = crypto.randomUUID();  // "550e8400..."

// Uppercase
const upper = crypto.randomUUID().toUpperCase();  // "550E8400..."

Python:

# Lowercase (default)
lower = str(uuid.uuid4())  # "550e8400..."

# Uppercase
upper = str(uuid.uuid4()).upper()  # "550E8400..."

System compatibility: Most systems accept both cases. If you need consistency:

1. Choose one case for your application
2. Convert on input if necessary
3. Store in a consistent format

"Why are there/aren't there dashes in my UUID?"

Cause: The Remove Dashes formatting option.

With dashes (36 characters):

550e8400-e29b-41d4-a716-446655440000

Without dashes (32 characters):

550e8400e29b41d4a716446655440000

When you need no dashes:

• Fixed-length database columns (32 chars)
• URL parameters (cleaner appearance)
• Systems requiring continuous hex strings
• Compact representation

When to keep dashes:

• Standard UUID compatibility
• Human readability
• Most UUID parsers expect dashes
• Database UUID/GUID types

Converting between formats:

// Add dashes
function addDashes(uuid) {
  return uuid.replace(/(.{8})(.{4})(.{4})(.{4})(.{12})/, '$1-$2-$3-$4-$5');
}

// Remove dashes
function removeDashes(uuid) {
  return uuid.replace(/-/g, '');
}

"Can UUIDs actually collide?"

Short answer: Theoretically yes, practically no.

The math:

• UUID v4 space: ~5.3 x 1036 possible values
• Birthday paradox: 50% collision chance at ~2.7 x 1018 UUIDs
• For practical purposes: collision probability ~ 0

Real-world perspective:

To get even a 0.01% collision chance:

• Generate ~1014 UUIDs (100 trillion)
• At 1 million/second: would take ~3 years of continuous generation

Database protection:

Still use UNIQUE constraints:

CREATE TABLE resources (
  id UUID PRIMARY KEY,  -- Enforces uniqueness
  ...
);

Why?

• Protects against bugs in UUID generation
• Catches accidental duplicates from data imports
• Provides database-level guarantee

If collision does occur: Regenerate the UUID. Your application should handle this gracefully (though it will likely never happen).

"Should I use UUID v1 or v4?"

Quick decision guide:

Use UUID v4 if:

• You need a general-purpose unique ID
• Privacy is important
• Simplicity is valued
• Time-ordering doesn't matter
• Public-facing identifiers

Use UUID v1 if:

• You need temporal ordering
• Timestamp extraction is valuable
• Internal systems only
• Clock coordination is available

Consider UUID v7 (newer) if:

• You need time-ordering WITHOUT v1 privacy issues
• Database index performance matters
• You're building a new system
• Libraries support it

Privacy comparison:

Default recommendation: UUID v4 for most use cases.

"Is a UUID safe for password reset/session tokens?"

No, not by itself.

Why UUIDs aren't sufficient:

Lack of expiration: UUIDs have no built-in expiration - once generated, they're valid forever unless you track expiration separately.

No cryptographic binding: UUIDs aren't signed or verified. Anyone with the UUID can use it.

Insufficient entropy for critical security: While 122 bits is strong, security tokens should use 256+ bits and proper cryptographic construction.

Proper password reset approach:

// Generate cryptographic token (not just UUID)
const tokenBytes = new Uint8Array(32); // 256 bits
crypto.getRandomValues(tokenBytes);
const resetToken = btoa(String.fromCharCode(...tokenBytes));

// Store with expiration
const expiresAt = Date.now() + (60 * 60 * 1000); // 1 hour
database.saveResetToken(userId, resetToken, expiresAt);

UUID as identifier + proper security:

// UUID identifies the reset request
const requestId = crypto.randomUUID();

// But security comes from:
// 1. Cryptographic token
// 2. Expiration time
// 3. One-time use enforcement
// 4. Rate limiting
// 5. Email verification

"What happens if I generate millions of UUIDs?"

Performance: Modern UUID generation is extremely fast:

• JavaScript crypto.randomUUID(): ~1-2 million/second
• Python uuid.uuid4(): ~500,000-1,000,000/second
• Java UUID.randomUUID(): ~1-2 million/second

Memory: Each UUID as a string:

• With dashes: 36 bytes
• Without dashes: 32 bytes
• As binary: 16 bytes

1 million UUIDs:

• Text format: ~36 MB
• Binary format: ~16 MB

Browser limits: Browser memory can handle millions of UUIDs, but performance may degrade when manipulating very large arrays.

Best practice for bulk generation:

// Generate on demand rather than pre-generating
function* uuidGenerator() {
  while (true) {
    yield crypto.randomUUID();
  }
}

const gen = uuidGenerator();
const uuid1 = gen.next().value;
const uuid2 = gen.next().value;

Frequently Asked Questions (FAQ)

1. What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit identifier designed to be unique across space and time without requiring central coordination. UUIDs are standardized by RFC 4122 and RFC 9562.

Format: 32 hexadecimal digits displayed in five groups separated by hyphens:

550e8400-e29b-41d4-a716-446655440000

Purpose: Provide globally unique identifiers for objects, records, resources, and entities in distributed systems without requiring a central registry or coordination.

Common uses:

• Database primary keys
• API request IDs
• File names
• Session identifiers
• Resource references

2. What's the difference between UUID and GUID?

UUID and GUID are essentially the same thing:

UUID (Universally Unique Identifier):

• Standard term in IETF specifications (RFC 4122, RFC 9562)
• Used in Unix/Linux systems, Java, Python, web standards
• Industry-standard terminology

GUID (Globally Unique Identifier):

• Microsoft's term for the same concept
• Used in Windows, .NET, COM/DCOM technologies
• Follows the same RFC 4122 standard

Compatibility: A UUID generated on any platform is compatible with GUID-expecting systems. The 128-bit structure and format are identical - only the terminology differs.

Example:

UUID: 550e8400-e29b-41d4-a716-446655440000
GUID: 550e8400-e29b-41d4-a716-446655440000
(They're the same!)

3. What UUID versions does this generator support?

Our UUID generator supports three versions:

UUID v4 (Random):

• Cryptographically random 128-bit identifier
• Most commonly used version
• 122 bits of randomness
• Best for general-purpose unique IDs

UUID v1 (Time-based):

• Encodes timestamp and node identifier
• Sortable by creation time
• May expose MAC address (privacy consideration)
• Useful when temporal ordering matters

Nil UUID:

• All zeros: 00000000-0000-0000-0000-000000000000
• Represents "no UUID" or null value
• Used as placeholder or default value

Recommendation: Use UUID v4 for most applications unless you specifically need time-based properties.

4. What is UUID v4 and why is it common?

UUID v4 is a randomly generated universally unique identifier with 122 bits of randomness (6 bits are used for version and variant markers).

Why it's the most common:

Simplicity:

• No coordination required
• No clock synchronization needed
• Just generate random bits

Privacy:

• No embedded metadata
• Doesn't reveal creation time
• Doesn't expose MAC address

Universality:

• Supported in all major languages and frameworks
• Browser-native with crypto.randomUUID()
• Default choice for most UUID libraries

Security:

• Uses cryptographically secure random number generators
• Unpredictable values
• Hard to guess (not enumerable)

Example generation:

const uuid = crypto.randomUUID();
// Output: "550e8400-e29b-41d4-a716-446655440000"

When to use: General-purpose unique identifiers in distributed systems, databases, APIs, and applications.

5. What is UUID v1 and does it expose device/time info?

UUID v1 is a time-based UUID that encodes:

• Timestamp: When the UUID was created (60-bit Gregorian timestamp)
• Clock sequence: Counter for handling clock adjustments
• Node ID: 48-bit identifier, often the MAC address

Privacy concerns:

MAC address exposure: If the node ID uses the actual MAC address, v1 UUIDs can:

• Reveal which hardware generated the UUID
• Enable tracking of UUIDs back to specific machines
• Potentially identify organizational infrastructure

Timestamp exposure: The embedded timestamp reveals:

• When the UUID was created
• Relative timing of UUID generations
• Activity patterns

Example extraction:

import uuid

# Generate v1 UUID
id_v1 = uuid.uuid1()
print(id_v1)  # 6ba7b810-9dad-11d1-80b4-00c04fd430c8

# Extract timestamp (using uuid library functions)
# Can determine creation time from UUID

Mitigation: Some implementations use random node IDs instead of real MAC addresses, reducing privacy risk while maintaining time-based properties.

When to avoid v1:

• Public-facing APIs
• User-facing identifiers
• Systems where privacy is critical

Alternative: UUID v7 provides time-ordering without MAC address exposure.

6. What is a nil UUID and when should I use it?

A nil UUID is a special UUID with all 128 bits set to zero:

00000000-0000-0000-0000-000000000000

When to use nil UUID:

Default/placeholder value:

user_id = uuid.UUID('00000000-0000-0000-0000-000000000000')
# Before assigning actual UUID

Null checks:

if (userId === '00000000-0000-0000-0000-000000000000') {
  console.log('No user assigned');
}

Database defaults:

CREATE TABLE sessions (
  id UUID DEFAULT '00000000-0000-0000-0000-000000000000'::uuid
);

Protocol requirements: Some APIs or protocols expect UUID fields but allow nil for "none" or "not applicable."

Programming language support:

# Python
nil = uuid.UUID(int=0)

# Java
UUID nil = new UUID(0L, 0L);

# C#
Guid empty = Guid.Empty;

Not the same as null: Nil UUID is a valid UUID value (all zeros), whereas null/None means absence of a UUID field entirely.

7. Can I generate multiple UUIDs at once?

Yes! Our generator supports bulk UUID generation:

Using the tool:

1. Set "Number of UUIDs" to desired quantity (1-100)
2. Click "Generate"
3. Receive all UUIDs at once

Use cases for bulk generation:

• Populating test databases
• Pre-generating ID pools
• Batch data processing
• Creating multiple resources simultaneously

Programmatic bulk generation:

JavaScript:

// Generate 100 UUIDs
const uuids = Array.from({ length: 100 }, () => crypto.randomUUID());

Python:

# Generate 100 UUIDs
uuids = [uuid.uuid4() for _ in range(100)]

Java:

// Generate 100 UUIDs
List<UUID> uuids = IntStream.range(0, 100)
    .mapToObj(i -> UUID.randomUUID())
    .collect(Collectors.toList());

Performance: Modern generators can produce millions of UUIDs per second, so bulk generation is very fast.

8. Can I generate UUIDs without hyphens / in uppercase?

Yes! Our generator offers formatting options:

Remove Dashes:

• Enabled: 550e8400e29b41d4a716446655440000 (32 chars)
• Disabled: 550e8400-e29b-41d4-a716-446655440000 (36 chars)

Uppercase:

• Enabled: 550E8400-E29B-41D4-A716-446655440000
• Disabled: 550e8400-e29b-41d4-a716-446655440000

Combining options:

Uppercase + Remove Dashes:
550E8400E29B41D4A716446655440000

Why these options matter:

No dashes:

• URL-friendly (no special characters)
• Fixed-length database columns
• Compact representation
• Hash-like appearance

Uppercase:

• Coding style preferences
• System compatibility requirements
• Visual consistency

Converting format programmatically:

JavaScript:

const uuid = crypto.randomUUID();

// Remove dashes
const noDash = uuid.replace(/-/g, '');

// Uppercase
const upper = uuid.toUpperCase();

// Both
const upperNoDash = uuid.toUpperCase().replace(/-/g, '');

9. Are UUIDs safe to use as security tokens?

No, UUIDs should NOT be used as security tokens by themselves.

Why UUIDs are not security tokens:

Design purpose: UUIDs are identifiers, not secrets. RFC 4122 explicitly states:

"Do not assume that UUIDs are hard to guess; they should not be used as security capabilities."

Insufficient for sensitive operations:

• No expiration mechanism
• No cryptographic signing
• Not designed for secret keeping
• 122 bits may be insufficient for high-security contexts

Examples of UNSAFE usage:

Password reset tokens (just UUID) API keys (UUID alone) Session tokens (without additional security) Authorization capabilities

Proper security token approach:

// Generate cryptographic token (256 bits)
const tokenBytes = new Uint8Array(32);
crypto.getRandomValues(tokenBytes);
const secureToken = btoa(String.fromCharCode(...tokenBytes));

// Include expiration and signing
const jwt = createSignedToken({
  userId: crypto.randomUUID(),  // UUID as identifier
  expiresAt: Date.now() + 3600000,
  purpose: 'password-reset'
}, secretKey);

UUIDs CAN be part of security:

• As resource identifiers (with proper auth)
• As correlation/request IDs
• As database primary keys
• Combined with proper authentication layers

Bottom line: Use UUIDs for identification, not authentication or authorization.

10. How do I generate a UUID in JavaScript / Python / Java?

JavaScript (Modern browsers & Node.js):

// Browser (Chrome 92+, Firefox 95+, Safari 15.4+)
const uuid = crypto.randomUUID();
console.log(uuid);
// Output: "550e8400-e29b-41d4-a716-446655440000"

// Node.js (v14.17.0+)
const crypto = require('crypto');
const uuid = crypto.randomUUID();

Python:

import uuid

# UUID v4 (random)
id_v4 = uuid.uuid4()
print(id_v4)
# Output: 550e8400-e29b-41d4-a716-446655440000

# UUID v1 (time-based)
id_v1 = uuid.uuid1()
print(id_v1)
# Output: 6ba7b810-9dad-11d1-80b4-00c04fd430c8

# Convert to string
uuid_str = str(id_v4)

# Uppercase, no dashes
uuid_clean = id_v4.hex.upper()

Java:

import java.util.UUID;

// Generate UUID v4
UUID uuid = UUID.randomUUID();
System.out.println(uuid);
// Output: 550e8400-e29b-41d4-a716-446655440000

// Convert to string
String uuidStr = uuid.toString();

// Uppercase
String uuidUpper = uuid.toString().toUpperCase();

// Without dashes
String uuidNoDash = uuid.toString().replace("-", "");

All three methods:

• Use cryptographically secure random number generators
• Produce RFC 4122-compliant UUIDs
• Are built into standard libraries (no external dependencies)

11. What is UUID v7 and why is it time-ordered?

UUID v7 is a newer UUID version defined in RFC 9562 (2024) that combines time-ordering with randomness.

Structure:

• 48 bits: Unix timestamp (milliseconds)
• 74 bits: Random data
• 6 bits: Version and variant markers

Example:

017F22E2-79B0-7CC3-98C4-DC0C0C07398F

  timestamp

Why it's important:

Better than v1:

• No MAC address exposure (better privacy)
• Standard Unix timestamp (easier to work with)
• Simpler implementation

Better than v4 for databases:

• Sortable by creation time
• Better B-tree index performance (sequential writes)
• Reduced index fragmentation

When to use UUID v7:

Database primary keys: Time-ordered UUIDs reduce index fragmentation compared to random v4 UUIDs, improving write performance.

Distributed systems: Combines benefits of UUIDs (no coordination) with timestamp-based ordering.

Event logging: Natural chronological sorting for events and transactions.

Current status: UUID v7 is standardized but not yet universally supported in all programming languages. Expect broader adoption in newer library versions and frameworks.

Alternative solutions: Until v7 is widely available, consider:

• ULID (Universally Unique Lexicographically Sortable Identifier)
• Snowflake IDs
• Custom time-prefixed UUIDs