UUID Generator

• UUID v1 combines a timestamp with the machine's MAC address — guaranteed unique but reveals creation time and hardware identity, creating privacy concerns.
• UUID v3 and v5 are deterministic hashes: v3 uses MD5, v5 uses SHA-1. Given the same namespace and name, they always produce the same UUID — useful for generating consistent identifiers from natural keys (e.g., converting email addresses to user IDs).
• UUID v4 uses 122 bits of random data, providing the strongest uniqueness guarantee without leaking any information.
• UUID v7 (RFC 9562, 2024) embeds a Unix timestamp in the first 48 bits while keeping 74 random bits — sortable by creation time, making it ideal for database primary keys where index performance matters.

For most applications, v4 is the default choice; switch to v7 for database primary keys where insertion order matters.

UUID v4 uses 122 random bits, yielding 5.3 × 10^36 possible values. The birthday problem determines collision probability: after generating 2.7 × 10^18 (2.7 quintillion) UUIDs, there is a 50% chance of one collision.

In practical terms, generating 1 billion UUIDs per second for 85 years reaches this threshold. At more realistic scales — a system generating 1 million UUIDs per day — the probability of any collision in 100 years is approximately 1 in 10^24.

This assumes a proper random number generator (CSPRNG); using Math.random() in JavaScript (which is not cryptographically secure) reduces entropy and increases collision risk. Always use crypto.randomUUID(), uuid v4 libraries, or database-native UUID functions for production systems.

UUIDs as primary keys enable decentralized ID generation (applications create IDs without database roundtrips) and prevent enumeration attacks (users cannot guess other records' IDs).

However, random UUID v4 values hurt B-tree index performance — random insertions cause page splits and fragmentation, increasing write amplification by 2-5x compared to sequential integer keys. UUID v7 solves this with timestamp-prefixed randomness, providing both uniqueness and sequential ordering.

Storage cost is also higher: 16 bytes versus 4-8 bytes for integers, significant in tables with billions of rows and multiple indexes.

A common pattern combines UUIDs as public-facing identifiers with integer auto-increment keys internally, joining tables on the efficient integer while exposing only the secure UUID to APIs and URLs.

A UUID (Universally Unique Identifier) is a 128-bit value designed to be unique across space and time without a central registration authority, as defined by IETF RFC 9562 (which obsoletes the earlier RFC 4122).

Its 128 bits are written as 32 hexadecimal characters grouped in an 8-4-4-4-12 pattern, such as 550e8400-e29b-41d4-a716-446655440000. Specific bits are reserved: the 13th hex digit encodes the version, and the top bits of the 17th hex digit encode the variant.

The remaining bits carry random data, a timestamp, or a hashed name depending on the version. Because the addressable space is 2^122, independent generators can safely mint identifiers without ever coordinating.

The simplest way to generate a UUID is a built-in language function that calls a cryptographically secure random source.

• In JavaScript, crypto.randomUUID() returns a v4 UUID and is documented on MDN Web Docs as part of the Web Crypto API, available in modern browsers and Node.js 14.17+.
• In Python, the standard-library uuid module provides uuid.uuid4() for random and uuid.uuid1() for timestamp-based values.
• In PostgreSQL, gen_random_uuid() produces a v4 UUID, while MySQL 8 offers UUID() for a v1-style value.

All of these emit RFC 9562-compliant strings, so IDs generated in one language interoperate cleanly with another.

Yes, a GUID and a UUID are the same 128-bit identifier; GUID (Globally Unique Identifier) is simply Microsoft's terminology for the standard UUID defined by IETF RFC 9562. They are binary-compatible, so a value created by Windows or .NET can be consumed by any RFC-compliant system and vice versa.

The only routine difference is presentation: Microsoft tooling often wraps the value in curly braces, for example {550e8400-e29b-41d4-a716-446655440000}, and some COM APIs historically uppercased the hex.

A subtle caveat is byte order — Microsoft's binary GUID stores the first three fields in little-endian, which matters only when parsing raw bytes, not the canonical hyphenated string form.

A UUID is not a secret and should never be treated as one, even when its random bits come from a cryptographically secure generator. RFC 9562 explicitly warns that UUIDs offer no built-in security and must not be assumed hard to guess; OWASP similarly cautions against using identifiers as authorization tokens.

Version 4 draws 122 bits from a CSPRNG, so it is impractical to predict, but version 1 and version 7 embed timestamps that leak creation time, and version 3 and version 5 are deterministic hashes of a known namespace and name.

For session tokens, password resets, or API keys, generate dedicated high-entropy secrets rather than relying on a UUID's structure for protection.

The version and variant fields are fixed bit patterns embedded in every RFC 9562 UUID that tell parsers how the value was generated.

The version occupies the four most significant bits of the seventh byte (the 13th hex digit), so a v4 UUID always shows a 4 there and a v7 always shows a 7. The variant sits in the two or three most significant bits of the ninth byte (the 17th hex digit), which for the standard IETF variant makes that digit one of 8, 9, a, or b.

This is why a valid v4 UUID matches the pattern xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. Checking these fixed positions is the correct way to validate or classify a UUID rather than a loose length check.

Bulk UUID generation is useful for seeding databases, building test fixtures, load-testing, and populating mock APIs, and this tool can output many valid identifiers in a single click. Because each UUID is created independently from a random or timestamp source per RFC 9562, generating a batch carries no meaningful collision risk even at large counts.

For repeatable test data, prefer deterministic version 5 UUIDs derived from a fixed namespace and name so the same input always yields the same identifier across runs.

When seeding production-scale tables, consider version 7 so the bulk-inserted rows land in roughly sequential index order, which keeps B-tree pages compact and reduces write amplification during the import.

Store UUIDs in a native 16-byte binary type whenever your database supports one, because keeping them as 36-character text wastes more than double the space and slows index comparisons. PostgreSQL provides a dedicated uuid column type, while MySQL and SQL Server commonly use BINARY(16) with conversion functions to and from the hyphenated string.

As RFC 9562 notes, UUIDs are case-insensitive and should be normalized — typically to lowercase — before storage so lookups stay consistent.

If you use UUIDs as primary keys, prefer version 7 to preserve insertion locality; if you must use version 4, some engines let you rearrange timestamp bytes, though version 7 is the standards-based solution to the same fragmentation problem.

The most common UUID mistake is using a non-cryptographic random source such as JavaScript's Math.random(), which is not a CSPRNG and can produce biased or predictable values; MDN recommends crypto.randomUUID() or the Web Crypto API instead.

Other frequent errors include:

• treating the nil UUID (all zeros) as a real identifier
• assuming UUIDs are secret enough to authorize access
• storing them as text when a 16-byte binary column would be far more efficient

Developers also mix versions inconsistently, or rely on version 1 in privacy-sensitive contexts where its embedded timestamp and historical MAC address leak information. Finally, comparing UUIDs case-sensitively causes false mismatches, since RFC 9562 defines them as case-insensitive.