Free Online UUID Generator (v1 & v4)

Unique identifiers are a fundamental requirement in software development — every database record, user session, API resource, distributed transaction, and file needs a way to be unambiguously referenced. UUID (Universally Unique Identifier), also known as GUID (Globally Unique Identifier) in Microsoft ecosystems, is the most widely adopted standard for generating unique identifiers that do not require central coordination. Understanding UUID versions, their properties, and when to use each one is practical knowledge for any developer building systems that need to manage distinct entities.

What Is a UUID?

A UUID is a 128-bit number standardized in RFC 4122, typically displayed as 32 hexadecimal characters formatted into five groups separated by hyphens: 550e8400-e29b-41d4-a716-446655440000. The five groups have 8, 4, 4, 4, and 12 hexadecimal digits respectively, totaling 32 hex digits (128 bits). Within the 128 bits, 4 bits encode the version number and 2 bits encode the variant, leaving 122 bits for the actual unique value. The standard UUID format is case-insensitive — uppercase and lowercase hex characters are equivalent — though lowercase is the modern convention.

UUID Version 4 is by far the most commonly used: it fills all 122 bits with random values from a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). The probability of a collision — two UUIDs being identical — is so low as to be practically impossible: with 5.3 × 10^36 possible values, you would need to generate approximately 2.7 × 10^18 UUIDs to have even a 50% chance of a single collision. For all practical applications, UUID v4 values are guaranteed to be unique without any coordination between the generating systems.

UUID Versions: Understanding the Differences

UUID v1 combines the current timestamp with the MAC address of the generating machine to produce identifiers that are chronologically sortable and traceable to the originating device. The traceability to a MAC address raised privacy concerns, and the use of the host's clock means that rapid generation on a single machine can produce duplicate UUIDs if the clock doesn't advance fast enough. UUID v1 is still used in some legacy systems and protocols but is generally deprecated in favor of newer versions for new applications.

UUID v3 and v5 are deterministic — given the same inputs (a namespace UUID and a name string), they always produce the same UUID. This is useful for generating stable identifiers for known entities: a v5 UUID from the namespace for DNS names and the hostname "example.com" will always be the same UUID, enabling reproducible ID generation without storing a mapping table. The difference between v3 and v5 is the hash algorithm used: v3 uses MD5 and v5 uses SHA-1. New applications should use v5 (or v8 if SHA-256 is needed).

UUID v7: The Modern Standard

UUID version 7, finalized in the IETF RFC 9562 standard (2024), addresses the main practical limitation of UUID v4: poor database index performance. UUID v4's random values are inserted at random positions in B-tree indexes, causing index fragmentation and degrading write performance at scale. UUID v7 uses a timestamp prefix — the current millisecond Unix timestamp occupies the first 48 bits — followed by random bits. This produces UUIDs that are approximately time-ordered, enabling efficient sequential insertion into database indexes while maintaining uniqueness without central coordination.

UUID v7 is rapidly becoming the recommended choice for database primary keys in distributed systems. It retains all the benefits of UUID v4 (no coordination, works across distributed systems) while achieving index performance comparable to auto-increment integers. The timestamp prefix also means UUID v7 values carry implicit ordering information — you can roughly determine the creation time of a record from its UUID, which is useful for debugging and data analysis. Major databases including PostgreSQL 17+ support UUID v7 natively, and UUID libraries in most languages have added v7 generation.

UUIDs as Database Primary Keys

The traditional approach to database primary keys is auto-increment integers (1, 2, 3...) — simple, sequential, and efficient for indexing. UUIDs as primary keys offer significant advantages for distributed systems: they can be generated client-side without a database roundtrip, they work seamlessly across multiple database shards or replicas, they do not reveal the sequential order or count of records to external users, and they avoid ID collision when merging data from separate databases.

The tradeoff is performance: UUID v4 as a primary key in a high-write database causes index fragmentation and larger storage overhead compared to integers. UUID v7 addresses the fragmentation issue. For single-instance databases where security through obscurity of record counts is not a concern, auto-increment integers remain a good default. For microservices architectures, multi-tenant systems, or any scenario where IDs are generated outside the database layer, UUID v7 is the current best practice recommendation for new systems.

UUIDs in APIs and URLs

Using UUIDs as resource identifiers in REST APIs prevents the enumeration attacks that sequential integer IDs enable. An API that uses /users/1234 in URLs allows attackers to iterate through user IDs to harvest data or probe for valid accounts. An API using /users/550e8400-e29b-41d4-a716-446655440000 cannot be enumerated — the 2^122 possible values make guessing valid IDs computationally infeasible. This is particularly important for APIs exposing sensitive resources. UUIDs in URLs should use the lowercase hyphenated format for consistency, and API responses should validate that provided UUID strings are well-formed before using them in database queries to prevent injection attacks.