Quick answer
A UUID (universally unique identifier) is a 128-bit value, usually written as 36 characters like 3f2b8c1e-7d4a-4f6b-9a21-5c0e8d7b1f42, that can be generated independently on any machine with a negligible chance of two ever being the same.
Formula: 128 bits = 32 hex digits, written 8-4-4-4-12
What is a UUID?
A UUID (universally unique identifier) is a 128-bit number used as an ID. Any system can create one without asking a central server, and the chance that two systems ever create the same one is small enough to ignore. Microsoft calls the same thing a GUID.
The current standard is RFC 9562 (May 2024), which replaced RFC 4122 and added versions 6, 7 and 8.
The format
A UUID is written as 32 hexadecimal digits in five groups, 36 characters with the hyphens:
3f2b8c1e-7d4a-4f6b-9a21-5c0e8d7b1f42
- Groups are 8-4-4-4-12 characters.
- The first digit of the third group is the version (here
4). - The first digit of the fourth group holds the variant; for standard UUIDs it is 8, 9, a or b.
Versions
| Version | Built from | Use it when |
|---|---|---|
| v1 / v6 | Timestamp + node (often a MAC address) | Legacy systems; v6 is the sortable reordering of v1 |
| v3 / v5 | Hash (MD5 / SHA-1) of a namespace and a name | The same input must always give the same id |
| v4 | 122 random bits | You need a random unique key |
| v7 | Unix time in milliseconds + random bits | Database keys, or ids that should sort by creation time |
v4 vs v7: both are safe to generate anywhere. Random v4 keys land all over a database index, which slows inserts on large tables. v7 keys increase over time, so new rows go at the end of the index. The trade-off is that a v7 id reveals roughly when it was created.
How likely is a collision?
A v4 UUID has 122 random bits, about 5.3 × 10³⁶ possible values. By the birthday bound you would need roughly 2.7 × 10¹⁸ UUIDs (2.7 quintillion) for a 50% chance that any two match. Real collisions come from bad random number generators or copied ids, not from the math.
Generating one
| Language | Code |
|---|---|
| JavaScript (browser, Node 19+) | crypto.randomUUID() |
| Python | import uuid; uuid.uuid4() |
| PostgreSQL 13+ | gen_random_uuid() |
| Go | github.com/google/uuid → uuid.New() |
| Command line (macOS, Linux) | uuidgen |
crypto.randomUUID() and the others above generate v4. Support for v7 is still arriving; PostgreSQL 18 adds uuidv7(), and most languages have a library.
UUIDs in analytics
- Event deduplication. Give each business event (an order, a signup) a stable id, so a retry or a second sender does not create a second row.
- Anonymous ids. Many SDKs store a random UUID on the device to recognise it between sessions.
- Joining data. A UUID generated at the source lets you join analytics events with your own database rows.
In TapCub, server-side events take an insert_id as an idempotency key: if the same key arrives again with an event time within 1 day, the later copy is dropped and the first one wins. A UUID works, but if the event already has a natural id such as an order number, use that, so the browser and the server send the same key. See send server-side events. Note that the TapCub website script does not write a cookie by default; its visitor id is a salted hash, not a stored UUID.
See also
Was this explanation clear?
We use your answers to fix and expand this page.
Couldn’t send. Please try again in a minute.
Thanks for the feedback. We’ll use it to improve this page.You’ve already sent feedback on this page. Thanks.
Technical Engineer
Focuses on tracking code, SDKs, and API integrations, with practical guidance on implementation checks and troubleshooting.