UUID Generator

UUID (Universally Unique Identifier), also known as GUID (Globally Unique Identifier) in Microsoft terminology, is a 128-bit label standardized by RFC 9562 (formerly RFC 4122). It looks like 550e8400-e29b-41d4-a716-446655440000 — 32 hexadecimal digits in five groups separated by hyphens (8-4-4-4-12). There are approximately 5.3 × 10^36 possible UUIDs. The probability of generating two identical UUIDs is astronomically small: for v4, generating a billion UUIDs per second for 100 years, the probability of a single collision is roughly 50%. UUIDs are used as database primary keys, session tokens, file names, message IDs, and API object identifiers.

UUID v4 is completely random — 122 bits from a cryptographically secure random source, 6 bits for version and variant markers. No information about the generating machine or time. The most widely used version. UUID v7 is a 2024 standard (RFC 9562) that embeds a Unix millisecond timestamp in the first 48 bits, making them sortable chronologically. The remaining bits are random. This makes it ideal for database primary keys because sequential inserts benefit from B-tree index performance. UUID v1 embeds a 100-nanosecond timestamp since October 1582 plus the MAC address of the generating machine. Sortable but leaks system information — avoid in new applications.

For most use cases: UUID v4 is the safe default. Completely random, no information leakage, supported natively in all databases, ORMs, and languages. Use UUID v7 for database primary keys where you want chronological sortability — it dramatically improves index performance in PostgreSQL, MySQL/InnoDB, and SQL Server because sequential inserts avoid page splits. Prisma, Hibernate, and other ORMs are adding v7 support. Avoid UUID v1 in new code because it exposes your MAC address. If you are on PostgreSQL, the built-in gen_random_uuid() generates v4. For v7, use extensions or application-level generation.

ULID (Universally Unique Lexicographically Sortable Identifier) is an alternative to UUID designed for sorting. A ULID looks like 01ARZ3NDEKTSV4RRFFQ69G5FAV — 26 characters of Crockford Base32 encoding a 48-bit timestamp plus 80 bits of randomness. Advantages over UUID: lexicographically sortable, URL-safe with no special characters, slightly more compact (26 vs 36 chars). Disadvantages: not standardized by an RFC, less tooling support. UUID v7 largely solves the sortability problem that made ULID attractive, so new projects should prefer UUID v7 over ULID for better ecosystem support.

UUIDs as primary keys have significant advantages: globally unique without coordination between servers (no auto-increment conflicts in distributed systems), IDs do not expose row count or creation order, safe to generate application-side before insert. The main disadvantage of UUID v4 is index fragmentation: random UUIDs cause non-sequential inserts into B-tree indexes, leading to page splits and bloat. Solutions: use UUID v7 (time-ordered), store as UUID type (not VARCHAR(36)) for 16 bytes vs 36 bytes, or use InnoDB's clustered index carefully. PostgreSQL: UUID type natively. MySQL: use BINARY(16) or UUID type (MySQL 8+). MongoDB uses its own ObjectID format which is similar in concept to UUID v7.

JavaScript/Node.js: crypto.randomUUID() (native, v4) or the uuid package for all versions. Python: import uuid; str(uuid.uuid4()). Go: github.com/google/uuid package. Java: UUID.randomUUID().toString(). C#: Guid.NewGuid().ToString(). PHP: Str::uuid() (Laravel) or ramsey/uuid. Ruby: SecureRandom.uuid. Rust: uuid crate. PostgreSQL: gen_random_uuid() for v4, uuid_generate_v4() with uuid-ossp extension. MySQL 8+: UUID() for v1, or install UDF for v4/v7.

Standard: the canonical UUID format with lowercase hex and hyphens: 550e8400-e29b-41d4-a716-446655440000. UPPERCASE: same format but uppercase: 550E8400-E29B-41D4-A716-446655440000. Some older Windows/Microsoft APIs expect uppercase GUIDs. No-dashes: hyphens removed, 32 hex characters: 550e8400e29b41d4a716446655440000. More compact, often used in URLs or when the 36-char format is inconvenient. Braces: Windows GUID format with curly braces: {550e8400-e29b-41d4-a716-446655440000}. Used in Windows Registry, COM interfaces, and .NET. URN: RFC 4122 URN format: urn:uuid:550e8400-e29b-41d4-a716-446655440000. For XML, RDF, and formal namespace contexts.

UUID v4 uniqueness relies on the quality of the random number generator. With a cryptographically secure source (like the Web Crypto API used here), generating 1 billion UUIDs per second for 86 years only gives a 50% chance of a single collision. In practice, UUID v4 collisions are effectively impossible at any realistic scale. UUID v1 uniqueness depends on the MAC address plus timestamp to the 100-nanosecond precision, which guarantees uniqueness on a single machine. The risk is if MAC addresses are faked or clocks run backwards. UUID v7 uses millisecond timestamps plus random bits — within the same millisecond, multiple UUIDs are distinguished by random bits, making collisions equally improbable as v4.

A UUID has 128 bits total, displayed as 32 hex characters in groups: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M position indicates the version (1, 4, 7, etc.). The N position indicates the variant: bits 10 mean RFC 4122 (the standard). For UUID v4: 122 bits are random, 4 bits are the version (0100 = 4), 2 bits are the variant (10). For UUID v7: bits 0-47 are a Unix timestamp in milliseconds, bits 48-51 are the version (0111 = 7), bits 52-53 are the variant, bits 54-127 are random. You can tell a UUID's version by looking at the first character of the third group: v4 starts with 4, v7 starts with 7, v1 starts with 1.

The nil UUID is all zeros: 00000000-0000-0000-0000-000000000000. It represents the absence of a UUID, similar to null or None. Uses: default value for UUID fields before a real ID is assigned, placeholder in data structures, sentinel value in protocols. The max UUID is all ones (hex ffffffff-ffff-ffff-ffff-ffffffffffff), sometimes used as a maximum boundary in range queries. RFC 9562 also defines a "nil" and "max" UUID as official special values. When querying by UUID in SQL, always use the database-native UUID type rather than string comparison to ensure proper index usage.