UUID Generator

UUID vs GUID — same thing, two names

If you work in the Microsoft ecosystem you know them as GUIDs (Globally Unique Identifiers); everywhere else they are UUIDs. The underlying value is identical: 128 bits laid out per RFC 4122. The only real difference is formatting convention — Windows tooling often wraps GUIDs in braces, like {3f8a2c1e-9b7d-4e5f-a6c3-1d2e3f4a5b6c}, which is why this generator offers a braces toggle alongside uppercase and hyphen-free styles.

Reading the five segments

A canonical UUID is written 8-4-4-4-12 hexadecimal characters. The segments have historical names — time_low, time_mid, time_hi_and_version, clock_seq, and node — inherited from the original time-and-MAC-address scheme. Two nibbles matter most in practice: the first character of the third group is the version (4 for random, 7 for time-ordered), and the first character of the fourth group is the variant (8, 9, a or b for RFC 4122). Open the anatomy strip above to see your UUID color-coded by segment.

Why v4 is the default — and when v7 helps

Version 4 UUIDs are essentially 122 random bits wearing a uniform. They need no coordination, no clock, and no information about the machine that created them, which makes them the safe default for database keys, session tokens and idempotency keys.

Version 7 embeds a 48-bit Unix-millisecond timestamp in the high bits, so freshly generated IDs sort roughly by creation time. That ordering keeps database B-tree indexes append-mostly, avoiding the random page splits that v4 causes at very high insert volumes. If you run a clustered primary key on PostgreSQL or MySQL at scale, v7 is worth a look; for almost everything else, v4 remains the standard choice.

Collision math in practice

How unique is "unique enough"? Version 4 UUIDs carry 122 bits of randomness, which gives about 5.3 × 10³⁶ possible values. By the birthday-paradox math, you would need to generate roughly 2.7 quintillion UUIDs before the probability of a single collision reaches 50%. Generate one billion UUIDs per second and that takes about 85 years of continuous output.

At application scale the risk is effectively zero: a system creating one million IDs per second for a full year accumulates a collision probability on the order of one in a hundred billion. Cosmic-ray bit flips in your storage are a far more realistic threat to your data than a UUID collision.

UUIDs in URLs, databases and code

In a relational database, store UUIDs in a native UUID type (PostgreSQL) or as 16-byte binary rather than a 36-character string — it halves the storage and speeds up comparisons. In REST URLs, the canonical hyphenated lowercase form is the portable choice. In code, prefer your platform's library over hand-rolled randomness: Node's crypto.randomUUID(), Python's uuid.uuid4(), Java's UUID.randomUUID() and .NET's Guid.NewGuid() all produce RFC-compliant v4 values identical in spirit to what this page generates.

Where UUIDs earn their keep

UUIDs shine wherever identifiers must be created independently: database primary keys generated in the application layer, idempotency keys for payment and API retries, correlation IDs across microservices, temporary file and upload names, device and installation identifiers, and session or invite tokens. Because any node can mint one without asking a central counter, they survive network partitions, multi-region writes and offline-first sync — situations where auto-increment integers fall apart.