How to Generate and Use UUIDs

Published 19 October 2026Guide for the UUID Generator

A UUID - a 36-character string like 3f2b8c1e-9a4d-4e6b-b1f0-7c5a2d8e9f01 - is the standard answer to "give this thing a name nobody else can have". No counter to coordinate, no server round-trip, no collision in practice. The cost is understanding what a UUID is good for, and what it is quietly bad at.

This guide covers the format, how the versions differ, and the usage rules that keep UUIDs from becoming a source of subtle bugs.

The format: 128 bits, grouped for humans

A UUID is a 128-bit number, written as 32 hex digits grouped 8-4-4-4-12, with the version and variant bits placed at fixed positions. The grouping is purely for human scanning - it is one number. 128 bits means about 3.4 x 10^38 possible values, which is why random UUIDs do not collide in any system you will ever build: generating one billion per second for a year still occupies a negligible fraction of the space.

The version digit (the first character of the third group) tells you how the UUID was made: 1 is time plus machine identity, 4 is random, 5 is a hash of a name, 7 is time-ordered. The variant digit (first character of the fourth group) indicates the layout - in modern UUIDs it is always 8, 9, a or b.

Version 4: what "random" buys you

Version 4 fills 122 bits from a random source (the remaining 6 are the version and variant markers). Three properties follow, and they shape how you should use v4 IDs:

Unguessable: with 122 random bits, guessing a valid ID is computationally impossible. UUIDs in URLs are safe against enumeration - the main reason APIs love them.
Unordered: consecutive UUIDs are scattered across the whole space. Sorting by UUID gives you no creation order - if you need "newest first", store a separate timestamp.
Uniform: no pattern leaks information about where or when the ID was generated (unlike v1, which encodes time and machine).

The usage rules that prevent real bugs

UUIDs fail in systems for the same few reasons, every time:

Stored as numbers: 128 bits does not fit in any standard numeric type. Store UUIDs as 36-character strings (or 16 raw bytes) - treating them as numbers loses precision in JavaScript, Excel and several ORMs.
Used as order: time-ordered display or "next ID" logic based on UUID values is wrong for v4. Add an explicit created_at column.
Two IDs for one thing: regenerating an ID on a retry or a re-export breaks referential integrity across the system. Generate once, reuse everywhere.
Mixed versions in one column: v1, v4 and v7 coexisting is legal but confusing; pick a version policy per system and stick to it.

Choosing a version for a new system

The default choice is version 4 - random, uniform, unguessable, and the least surprising. Choose differently only for a specific reason: version 7 (time-ordered) when you want database index locality and sortable IDs, accepting that the ID then leaks creation time; version 5 (name-hashed) when you need the same name to always produce the same ID, like a stable cache key derived from a URL; version 1 rarely, and mostly for legacy compatibility.

Frequently asked questions

Can someone guess or enumerate my UUIDs?

No practical chance with v4: 122 random bits is beyond brute force. That is exactly why UUIDs are safe to expose in URLs and API responses.

Why can't I sort UUIDs by creation time?

Version 4 IDs are random, so their order is meaningless. If you need time-orderable IDs, use version 7 (timestamp in the high bits) or keep a separate created_at field.

Should I use UUIDs as database primary keys?

Yes, with two caveats: store them as strings or fixed 16-byte columns (not floats or general-purpose numerics), and be aware that random v4 keys scatter across a B-tree index, which matters only at very high write volumes - v7 keys fix that.

Is my generated UUID stored anywhere?

No - generation happens in your browser. You copy the values out; nothing is uploaded or retained.