Reading a UUID: What the Hex Characters Actually Encode — and Why v1 Exposes Your Server's MAC Address

A UUID like 550e8400-e29b-41d4-a716-446655440000 looks random — but depending on which version generated it, it might encode the time it was created, the MAC address of the machine that created it, or a deterministic hash of a namespace and a name, and none of these are "just random"

The previous articles on this site covered UUID v1/v4/v5/v7 comparisons, alternative IDs (Snowflake, ULID, CUID2, NanoID), and UUID primary key performance across databases. This article addresses what the structure of a UUID actually encodes — reading the information hidden in the hexadecimal characters, and the practical consequences for security and privacy.

The UUID format: what each segment contains

Every UUID is a 128-bit value, displayed in the format: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Where:

• M is the version nibble (1 hex digit = 4 bits): indicates UUID version (1, 4, 5, 7, etc.)
• N is the variant nibble: indicates the UUID variant (for standard RFC 4122 UUIDs, this is 8, 9, a, or b — the two high bits are 10)

The version number is always readable from the UUID itself — the first digit of the third group reveals the version. 550e8400-e29b-**4**1d4-a716-446655440000 — the 4 in the third group's first position means this is a version 4 UUID.

Version 1: time + MAC address, readable by anyone with the UUID

UUID v1 encodes:

• A 60-bit timestamp (100-nanosecond intervals since October 15, 1582 — the adoption of the Gregorian calendar)
• A clock sequence (to handle collisions if the system clock is set backward)
• The MAC address of the network interface that generated the UUID

The MAC address is fully recoverable from the UUID — the last 12 hex characters of a v1 UUID are directly the MAC address. 550e8400-e29b-11d4-a716-**446655440000** — the last segment 446655440000 is the MAC address 44:66:55:44:00:00.

Privacy implication: generating a v1 UUID embeds the generating machine's MAC address into it. If v1 UUIDs are used as identifiers in a public-facing context (document IDs, record IDs, API keys) and those IDs are visible to users, you've disclosed the MAC address of your server to everyone who ever sees any UUID you generated. This was recognized as a privacy concern — it's part of why v4 (random) became dominant over v1 for most use cases.

The timestamp component: the creation time of any v1 UUID is exactly recoverable. If document IDs are v1 UUIDs, anyone can determine when each document was created by parsing the UUID — a potential information disclosure if creation timestamps are meant to be private.

Version 4: genuinely random (with a small asterisk)

UUID v4 replaces the time and MAC address with randomly generated bits, except for the 6 bits consumed by the version (4 bits) and variant (2 bits) markers. Of the 128 bits, 122 bits are random.

The "random" comes from whatever the system's random number generator provides — the UUID specification doesn't mandate CSPRNG, but all modern implementations use cryptographically secure randomness. If an implementation used a weak PRNG (the previous random-string article covered this distinction), v4 UUIDs would be guessable — which would be catastrophic if UUIDs are used as unguessable identifiers (session tokens, resource access keys).

Collision probability: with 122 random bits, the probability of any two v4 UUIDs colliding is approximately 1 in 5.3 × 10^36 — so astronomically unlikely that collisions are a theoretical concern but a practical non-issue for any real application. You'd need to generate approximately 2.7 × 10^18 UUIDs before you'd have a 50% chance of a single collision.

Version 5 (and v3): deterministic from input

UUID v5 generates a UUID from two inputs: a namespace UUID and a name string. The same namespace + name always produce the same UUID — every time, on every machine.

Example: the DNS namespace UUID (6ba7b810-9dad-11d1-80b4-00c04fd430c8) with the name example.com always produces cfbff0d1-9375-5685-968c-48ce8b15ae17.

Use cases: generating consistent IDs for entities that have natural unique identifiers — a company's domain, a product's SKU, a user's email address. Instead of storing a mapping between "the natural identifier" and "the UUID we assigned," you can compute the UUID on demand from the natural identifier without any lookup.

Security consideration: v5 UUIDs are not secret — given the namespace UUID (often a well-known standard value) and any natural identifier, anyone can compute the resulting UUID. If your security model requires that resource IDs be unguessable, v5 UUIDs are the wrong choice (someone who knows your namespace UUID and can guess identifiers can enumerate resource UUIDs).

Version 7: timestamp-ordered random (the current best choice for most databases)

UUID v7 combines a high-precision Unix millisecond timestamp (in the high bits) with random bits (in the low bits), producing UUIDs that:

• Are sortable by creation time — v7 UUIDs generated later sort later (crucial for database index performance, covered in the previous database performance article)
• Are random enough that the timestamp alone doesn't reveal which specific record a UUID identifies
• Don't expose MAC addresses or other machine-specific information

The timestamp is recoverable — you can determine when a v7 UUID was generated (within millisecond precision) by parsing it. Unlike v1's full machine identification, v7's timestamp disclosure is usually acceptable — knowing when a record was created is often benign, especially compared to v1's MAC address exposure.

When UUIDs shouldn't be used as security tokens

A UUID (any version) should not be used directly as a session token, API key, or anything whose purpose is to be unguessable by an adversary, unless you've explicitly analyzed whether the specific version's entropy is sufficient for your threat model.

The concern: v4 UUIDs have 122 random bits, which is cryptographically strong — but some UUID generators in some environments have historically used weak random sources. A session token stored as "a UUID" that was generated by a UUID library using weak randomness (not CSPRNG) is guessable.

The cleaner approach for security-sensitive identifiers: generate a purpose-built random token using the platform's CSPRNG (covered in the random string article) rather than repurposing a UUID library whose randomness quality may vary by implementation.

How to use the UUID Generator on sadiqbd.com

1. For database primary keys: use v7 if your database/ORM supports it; v4 if not — v7 gives index-friendly ordering; v4 gives safe randomness
2. For deterministic IDs from natural identifiers: use v5 with a fixed, private namespace UUID you define for your application — the privacy of your namespace UUID determines how guessable the resulting IDs are
3. Never use v1 in public-facing contexts: if generated UUIDs are ever visible to end users or in public URLs, v1's MAC address and timestamp disclosure may be unacceptable depending on your privacy requirements

Frequently Asked Questions

Can I extract the creation time from a UUID I received from a third-party API? It depends on the version. If it's a v1 UUID (version digit = 1), the creation timestamp is fully recoverable — extract the time-low, time-mid, and time-high fields, combine them, adjust for the Gregorian epoch offset, and convert to Unix time. If it's a v7 UUID (version digit = 7), the first 48 bits are a Unix millisecond timestamp, directly readable. If it's a v4 UUID, there's no timestamp embedded — it's random. The version digit (first digit of the third group) tells you which situation you're in.

Is the UUID Generator free? Yes — completely free, no sign-up required.

Try the UUID Generator free at sadiqbd.com — generate UUID v4 and v7 identifiers instantly.