UUID v4 Length: 36 Characters, 128 Bits, 16 Bytes

The numbers

128 bits. 16 raw bytes. 32 hexadecimal characters. 36 characters in the canonical form, because four hyphens are added in the 8-4-4-4-12 pattern.

Some systems wrap it in braces — {36b8f84d-...} — giving 38 characters. Microsoft tooling does this, and it is the usual reason a value fails validation after being copied from a Windows tool.

As Base64 it is 24 characters with padding, 22 without. A few APIs use that form to save URL space.

Which characters appear

Only 0-9, a-f and hyphens. Hexadecimal is case-insensitive, and RFC 9562 says to output lowercase and accept either — so normalise on input rather than rejecting uppercase.

Two positions are constrained rather than random: the version nibble (4 for v4) and the variant nibble (8, 9, a or b). A validator that accepts any hex in those spots will pass values that are not valid UUIDs.

Sizing the column

id UUID                    -- PostgreSQL: native, 16 bytes, indexes well
id BINARY(16)              -- MySQL: compact, fast, unreadable in results
id CHAR(36)                -- portable, readable, 36 bytes

PostgreSQL has a native UUID type — use it. MySQL does not; BINARY(16) with UUID_TO_BIN() halves storage and improves index performance, at the cost of needing BIN_TO_UUID() to read values.

Use CHAR(36), not VARCHAR(255). The length is fixed, and an oversized varchar invites truncated or padded values that silently never match.

Validating

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-4[0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$

This checks the version and variant positions, so it accepts only genuine v4 values. Drop the 4 and [89ab] constraints if you need to accept any UUID version.