UUID v4 Explained

Mostly random bits

Six bits are reserved for the version and RFC variant, leaving 122 random bits. With a cryptographically secure random generator, collisions remain negligible at ordinary application scale.

Length and text format

The canonical representation contains 32 hexadecimal digits plus four hyphens: 36 characters in 8-4-4-4-12 groups. Storage as raw bytes uses 16 bytes. Braces and uppercase letters are presentation variations, not different identifiers.

Read the version and variant

The first hex digit of the third group is 4. The first digit of the fourth group is normally 8, 9, a or b, which encodes the RFC variant. Other values are not an RFC-compatible UUID v4.

Check the version in code

To confirm that a stored value really is v4, parse it instead of eyeballing it. In Python, uuid.UUID(value).version returns 4, and None when the variant bits are not the RFC ones. In JavaScript the version digit sits at index 14 of the canonical string, so value[14] === '4' is enough once the shape has been validated. Parsing also absorbs uppercase letters and braces, which a plain string comparison does not.

Know when v7 is a better fit

Random v4 keys scatter writes in ordered database indexes. UUID v7 includes time ordering while retaining random bits, which can improve index locality when your runtime and schema support it.

Frequently asked questions

How long is a UUID v4?

36 characters in canonical text form, 32 hexadecimal digits without hyphens, or 16 bytes in binary form.

Can UUID v4 values collide?

The probability is extremely small with a secure 122-bit random source, but UUIDs are not a mathematical guarantee of uniqueness.

Can a UUID v4 be decoded?

You can read its version and variant, but it does not contain a timestamp, user identity or source data.

Should UUIDs be stored as strings?

Binary or native UUID database types are more compact; strings are convenient for interchange. Choose one canonical representation at boundaries.