UUID Generator

UUID Generator: Free Online Tool to Create Version 1, 4, 5, and 7 UUIDs Instantly

Universally Unique Identifiers "” UUIDs "” are the backbone of identity in distributed computing. They enable systems to generate unique identifiers without coordination, eliminate sequential ID guessing attacks, simplify database merges, and power everything from REST API resource URLs to Kubernetes object names to S3 bucket keys. Our free UUID generator creates RFC 4122 and RFC 9562 compliant UUIDs (v1, v4, v5, and v7) instantly in your browser "” no signup, no rate limits, no data sent to any server, no installation required.

Whether you need a single random UUID for a quick test, a bulk batch of 100 IDs for seeding a database, a deterministic v5 UUID derived from a URL or email address, or a time-ordered v7 UUID for a PostgreSQL primary key, this tool covers every use case with copy-to-clipboard, multiple output formats, and optional validation of your existing UUID strings.

What Is a UUID? The Complete Technical Definition

A UUID (Universally Unique Identifier), also called a GUID (Globally Unique Identifier) in Microsoft's terminology, is a 128-bit (16-byte) number defined by the IETF in RFC 4122 (and extended by RFC 9562 for newer versions). It is represented as a 36-character string of 32 lowercase hexadecimal digits grouped into five sections separated by hyphens:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

The sections are 8-4-4-4-12 hex characters in length. The M digit at position 13 encodes the version (1 through 8 in the current spec). The N digit at position 17 encodes the variant "” for RFC 4122 standard UUIDs, this is always 8, 9, a, or b, indicating the variant bits 10xx in binary.

A typical UUID looks like: 550e8400-e29b-41d4-a716-446655440000

The total UUID space is 2^128 "” approximately 340 undecillion (3.4 × 10^38) unique values. This number is so large that generating UUIDs at any realistic rate produces a collision probability that is negligible for any practical purpose. The birthday problem analysis shows that to reach even a 50% collision probability for v4 UUIDs, you would need to generate approximately 2.71 × 10^18 values "” more than two and a half quintillion identifiers.

The UUID specification has been a cornerstone of distributed systems since the late 1990s, with implementations in every programming language, database engine, and operating system. The consistency of the format across platforms is one of its greatest strengths.

UUID Version 1: Time and MAC Address

UUID Version 1 was the original specification and remains in widespread use today, particularly in Apache Cassandra and other systems that rely on time-sortable identifiers.

Version 1 UUIDs are constructed from three components: a 60-bit timestamp, a 14-bit clock sequence, and a 48-bit node identifier. The timestamp is measured in 100-nanosecond intervals since October 15, 1582 "” the date of the Gregorian calendar reform, chosen as the epoch for the UUID specification. This timestamp granularity (100 nanoseconds) means up to 10 million unique UUID v1 values can be generated per second per node without any clock sequence collision.

The clock sequence is a random value initialized at startup and incremented when the clock is set backwards or the node ID changes, preventing collisions during clock adjustments or VM migrations. The node ID was originally the MAC address of the generating network interface "” this made v1 UUIDs globally unique across all machines in the world, since MAC addresses are factory-assigned to be globally unique (though this guarantee has weakened with virtual machines and container environments).

The timestamp in v1 is stored in a somewhat awkward byte order: the least significant 32 bits of the timestamp go first (the time_low field), then the middle 16 bits, then the most significant 12 bits along with the version. This ordering makes v1 UUIDs not naturally sortable by their string representation even though they are time-based.

Privacy Concerns with v1

Because v1 UUIDs embed the generating machine's MAC address, they can reveal which physical or virtual machine created a given record. This exposes infrastructure details and links records together by originating machine "” a potential privacy issue in audit logs or user-facing identifiers. Modern v1 generators address this by using a cryptographically random 48-bit node ID instead of the real MAC address. Our tool generates v1 UUIDs with a random node ID.

When to Use Version 1

Use v1 when you need to extract an approximate creation time from the UUID itself without a separate timestamp column, or when you are integrating with systems (particularly Cassandra) that expect v1 for time-based partitioning. For new applications, prefer v7 which provides better time-ordering properties and a simpler timestamp format.

UUID Version 4: Cryptographically Random

UUID Version 4 is by far the most widely used UUID format in modern software. It consists of 122 bits of cryptographically random data with 6 bits reserved for version and variant markers. There is no timestamp, no node identifier, no determinism "” each v4 UUID is a fresh random value independent of when or where it was generated.

The simplicity of v4 is its greatest strength. Generating a v4 UUID requires only a cryptographically secure random number generator (CSPRNG), which every modern platform provides:

• Browsers and Node.js 19+: crypto.randomUUID()
• Node.js (any version): require('crypto').randomBytes(16)
• Python: uuid.uuid4() (uses os.urandom() internally)
• Java: UUID.randomUUID()
• Go: uuid.New() from github.com/google/uuid
• Rust: Uuid::new_v4() from the uuid crate
• PostgreSQL: gen_random_uuid()
• SQL Server: NEWID()
• MySQL 8+: UUID() generates v1; use gen_random_uuid() in PostgreSQL for v4

V4 UUIDs are ideal for database primary keys where you do not care about ordering, for session tokens (though dedicated CSPRNG tokens are slightly better for security-critical uses), for file names in storage systems, for request tracing IDs, for idempotency keys in payment and messaging systems, and for any situation where you need a unique opaque identifier that contains no deducible information.

The Tradeoff: Random UUIDs and Database Performance

The major tradeoff of v4 UUIDs as database primary keys is index fragmentation. SQL databases that use B-tree indexes for primary keys (MySQL InnoDB, SQL Server) store records in primary key order. When new records insert with random UUID primary keys, they scatter across the entire index rather than appending to the end. This causes B-tree page splits, random disk I/O, and significantly degraded write performance at scale.

For databases with high insert rates (millions of rows per day or more), this fragmentation is significant enough to matter. The solution is time-ordered UUIDs "” v7 or ULID "” that insert near the end of the B-tree like auto-increment integers while preserving uniqueness and opacity.

UUID Version 5: Deterministic Name-Based (SHA-1)

UUID Version 5 produces a deterministic UUID from two inputs: a namespace UUID and a name string. The output is the SHA-1 hash of the concatenated namespace bytes and name bytes, formatted as a UUID. The key property: given identical inputs (same namespace + same name), v5 always produces the same UUID "” on any machine, at any time, without any coordination.

This determinism makes v5 uniquely useful for scenarios where you need stable IDs for known values without maintaining a lookup table:

• URL normalization "” the UUID for https://example.com/page in the URL namespace is always the same, letting you create consistent references across systems
• DNS-based identifiers "” generate consistent IDs for hostnames or domain names
• Email to ID "” convert user email addresses to stable identifiers for data pipelines (though hashing emails has privacy implications)
• Content addressing "” create content-based identifiers from document text
• ETL and data migration "” derive consistent source-system IDs without lookup tables
• Idempotent record creation "” create the same ID for the same logical record, preventing duplicates in reprocessing scenarios

Predefined Namespaces

RFC 4122 defines four predefined namespace UUIDs for common use cases:

• DNS namespace: 6ba7b810-9dad-11d1-80b4-00c04fd430c8 "” for domain names
• URL namespace: 6ba7b811-9dad-11d1-80b4-00c04fd430c8 "” for URLs
• OID namespace: 6ba7b812-9dad-11d1-80b4-00c04fd430c8 "” for ISO OIDs
• X.500 DN namespace: 6ba7b814-9dad-11d1-80b4-00c04fd430c8 "” for X.500 distinguished names

You can also define custom namespace UUIDs for your application domain. As long as both systems use the same namespace UUID and the same input name, they will produce the same output UUID "” even if they never communicate.

V5 vs V3: Why SHA-1 over MD5?

UUID Version 3 is functionally identical to v5 but uses MD5 instead of SHA-1 for the hash. Since MD5 is considered cryptographically broken (collision attacks are feasible), v5 with SHA-1 is preferred for all new applications. Neither v3 nor v5 should be used when cryptographic security is required "” they are deterministic, meaning an attacker who knows the namespace and name can predict the UUID. Use v4 for security-sensitive identifiers.

UUID Version 7: Time-Ordered Random (The Modern Standard)

UUID Version 7, introduced in RFC 9562 published in 2024, is designed to solve the database performance problem of random v4 UUIDs while retaining their opacity and uniqueness. It is rapidly becoming the recommended choice for database primary keys.

A v7 UUID encodes a Unix millisecond timestamp in the most significant 48 bits, followed by 4 version bits, 12 bits of sequence/random data, 2 variant bits, and 62 bits of random data. The critical difference from v1: the timestamp is stored in a simple big-endian format in the most significant position, so v7 UUIDs naturally sort chronologically by their string representation.

This means v7 UUIDs have the best of both worlds:

• Natural sort order "” new records insert at the end of the B-tree, maintaining insert locality and preventing page splits
• Embedded timestamp "” the creation time is recoverable from the UUID itself without a separate column
• 122 bits of randomness "” the random component provides uniqueness collision resistance comparable to v4
• No hardware dependency "” no MAC address, no node ID, no machine fingerprinting
• Standard format "” standard 36-character UUID string, compatible with all UUID storage types

Database benchmarks consistently show v7 primary keys performing comparably to auto-increment integers for sequential inserts while providing the global uniqueness benefits of UUIDs. PostgreSQL 17 is expected to include a native uuidv7() function; several popular ORMs (Hibernate, Doctrine) have added v7 support. The uuid npm package, Python'suuid_utils library, and Go's github.com/google/uuid all support v7.

UUID as Database Primary Keys: Complete Analysis

Why Use UUIDs Instead of Auto-Increment?

Auto-increment integer primary keys are simple and performant for single-database applications with no distributed requirements. They become problematic in these scenarios:

Sequential enumeration attacks: Auto-increment IDs reveal business metrics. A competitor who places order #100 today and order #200 next week knows you processed 100 orders in a week. A malicious user who knows their user ID is 1047 knows your system has approximately 1046 other users. UUIDs are opaque "” they reveal nothing about volume, order, or business activity.

Distributed generation: Auto-increment requires a database round-trip to generate. You cannot create a record and know its ID until after the INSERT. With UUIDs, you generate the ID in application code before the INSERT "” enabling optimistic writes, better error handling, and the ability to reference the new record's ID in other operations within the same transaction.

Database merges and replication: When combining data from multiple database instances (sharding, migrations, multi-tenant consolidation), auto-increment IDs from different databases collide. UUIDs from different databases never collide.

Multi-tenant architectures: Each tenant's data can be identified by UUID without any coordination between tenant databases.

UUID Storage Strategy by Database

PostgreSQL: Has a native uuid type storing 16 bytes. Usegen_random_uuid() (PostgreSQL 13+) or uuid_generate_v4() (requiresuuid-ossp extension). For v7, use application-level generation until native support arrives.

MySQL / MariaDB: No native UUID type. Options: CHAR(36) stores the full text representation (36 bytes, readable but large); BINARY(16) stores raw bytes (16 bytes, fast but not human-readable); VARCHAR(36) is similar to CHAR(36) but variable-length. Use UUID_TO_BIN(UUID(), 1) with swap_flag=1 to reorder bytes for better InnoDB B-tree locality even with v1 timestamps.

SQL Server: The UNIQUEIDENTIFIER type stores 16 bytes natively.NEWID() generates a v4 UUID; NEWSEQUENTIALID() generates sequential GUIDs within a server restart. Note: SQL Server clusters the primary key by default, so random GUIDs with NEWID() can cause significant fragmentation "” use NEWSEQUENTIALID() or application-level v7 UUIDs for clustered primary keys.

MongoDB: Documents default to ObjectID (12-byte time+machine+process+counter), but UUIDs can be stored as Binary subtype 4 (standard UUID byte order) or subtype 3 (legacy UUID). Use subtype 4 for new applications.

DynamoDB: UUIDs are commonly used as partition keys stored as strings. The random distribution of v4 UUIDs actually helps with DynamoDB hot partition avoidance.

UUID vs Alternative Distributed ID Schemes

ULID: Universally Unique Lexicographically Sortable Identifier

ULID encodes a 48-bit Unix millisecond timestamp followed by 80 bits of randomness as a 26-character Crockford Base32 string (e.g., 01ARZ3NDEKTSV4RRFFQ69G5FAV). Key advantages over UUID: case-insensitive, URL-safe, naturally sortable as a string, more compact (26 chars vs 36 chars), and monotonic within the same millisecond (each subsequent ULID within a millisecond is guaranteed to be greater than the previous one). Disadvantages: less universal tooling support than UUID; the format is not an IETF standard.

Snowflake ID

Twitter/X's Snowflake ID is a 64-bit integer composed of: 41 bits of millisecond timestamp (since a custom epoch), 10 bits of machine ID, and 12 bits of sequence number. Advantages: fits in a standard BIGINT column (8 bytes vs 16 bytes for UUID); sortable; high throughput (4096 IDs per millisecond per machine). Disadvantages: requires centralized machine ID assignment (coordination problem); the 41-bit timestamp wraps around in ~69 years (from the chosen epoch); exposes infrastructure topology. Used by Twitter, Discord, Instagram.

NanoID

NanoID is a URL-safe alternative that generates customizable-length strings using random characters. A 21-character NanoID has collision resistance comparable to a UUID v4. It is smaller, URL-safe by default, and allows custom alphabets. Not an IETF standard and not compatible with UUID-expecting systems. Popular in JavaScript and frontend applications where string compactness matters.

CUID / CUID2

Collision-resistant Unique Identifier (CUID and its improved successor CUID2) are designed for horizontal scaling and are optimized for performance and collision resistance in database scenarios. CUID2 is cryptographically random with a timestamp prefix for sortability. Popular in the JavaScript/TypeScript ecosystem (Prisma uses CUID by default).

Generating UUIDs in Every Major Language

JavaScript and TypeScript

Modern approach "” works in browsers and Node.js 19+:

const id = crypto.randomUUID(); // Built-in, no dependencies

For older Node.js or other UUID versions, use the uuid package from npm:

import { v4 as uuidv4, v5 as uuidv5, v7 as uuidv7 } from 'uuid';

Python

Python's standard library uuid module has no dependencies:

import uuid; id = str(uuid.uuid4()) for v4 random.

id = str(uuid.uuid5(uuid.NAMESPACE_URL, 'https://example.com')) for v5 deterministic.

For v7, use pip install uuid-utils (a fast Rust-backed library).

Java

java.util.UUID.randomUUID().toString() generates a v4 UUID. The standard library does not support v5 or v7 "” use the java-uuid-generator orcom.github.f4b6a3:uuid-creator library for those.

Go

github.com/google/uuid supports v1, v3, v4, v5, v6, and v7:

id := uuid.New() // v4

id, err := uuid.NewV7() // v7

Rust

The uuid crate with feature flags:

Uuid::new_v4(), Uuid::new_v7(Timestamp::now(NoContext))

C#/.NET

Guid.NewGuid() generates a v4-equivalent GUID. For true UUID v7, theUUIDNext NuGet package provides standards-compliant generation.

PHP

The ramsey/uuid Composer package is the standard:

Uuid::uuid4()->toString(), Uuid::uuid7()->toString()

Ruby

require 'securerandom'; SecureRandom.uuid generates a v4 UUID (standard library). The uuidtools gem adds v1 and v5 support.

UUID Formats and Output Options

Standard Hyphenated Format

The canonical format: 550e8400-e29b-41d4-a716-446655440000. This is what most systems expect and is the format defined in RFC 4122. Use this unless there is a specific reason to use another format.

No Hyphens (Compact Hex)

550e8400e29b41d4a716446655440000 "” 32 characters, sometimes preferred in systems that store UUIDs in CHAR(32) columns or treat them as plain hex strings.

Uppercase

550E8400-E29B-41D4-A716-446655440000 "” some legacy systems and Windows APIs use uppercase GUIDs. UUIDs are defined as case-insensitive; treat both forms as equivalent.

Braces Format (Microsoft)

{550e8400-e29b-41d4-a716-446655440000} "” used in some Windows APIs and COM/DCOM interfaces. Our generator provides this format for Microsoft-ecosystem compatibility.

URN Format

urn:uuid:550e8400-e29b-41d4-a716-446655440000 "” the formal URN representation defined in RFC 4122 for use as a Uniform Resource Name.

Base64 / Base64URL

The 16-byte binary UUID encoded as Base64 gives 24 characters (22 meaningful + 2 padding) or 22 characters in Base64URL without padding. Used in some APIs and tokens where compactness is critical.

UUID Validation: Checking Format Correctness

A valid RFC 4122 UUID matches this regular expression:

/^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i

The version digit (position 13 in the string, first digit of the third group) must be 1"“8 for defined versions. The variant digit (position 17, first digit of the fourth group) must be 8, 9, a, or b for RFC 4122 variant UUIDs. Our tool includes a validator tab where you can paste any UUID string to check its format, version, and variant bits.

The nil UUID 00000000-0000-0000-0000-000000000000 (all zeros) is a special case defined in the spec as a sentinel meaning "no UUID" "” equivalent to null in most contexts. The max UUID ffffffff-ffff-ffff-ffff-ffffffffffff (all ones) is defined in RFC 9562 as another special sentinel.

Bulk UUID Generation and Use Cases

Our generator supports creating up to 100 UUIDs in a single operation, with output available as a newline-separated list, comma-separated values, JSON array, or SQL VALUES clause "” ready to paste directly into your development workflow:

• Database seeding "” generate primary keys for test fixtures and seed data
• Migration scripts "” pre-generate IDs for records being migrated to a new UUID-keyed table
• Idempotency key sets "” create batches of idempotency keys for bulk API operations
• Test data generation "” create realistic IDs for unit and integration test fixtures
• Mock API responses "” populate mock server responses with realistic-looking IDs
• Correlation IDs "” create request tracing IDs for logging and distributed tracing

UUID Collision Probability: The Math

The birthday problem gives us the formula for collision probability: given n randomly generated values from a space of N possible values, the probability of at least one collision is approximately:

P ≈ 1 - e^(-n²/2N)

For UUID v4, N = 2^122 ≈ 5.3 × 10^36. For a 50% collision probability: n ≈ 2.71 × 10^18. At one billion UUIDs generated per second, reaching that number would take approximately 85 years of continuous generation. Real applications generate far fewer UUIDs "” a busy API handling 10,000 requests per second generates fewer than 32 billion UUIDs per year, not even close to the collision threshold.

Privacy and Performance

All UUID generation in our tool runs entirely in your browser using the Web Crypto API (crypto.getRandomValues()) for maximum randomness quality. No UUID values are transmitted to our servers, logged, or stored anywhere. The tool works entirely offline once the page is loaded. You can generate any number of UUIDs with complete confidence that they remain private.