Base32hex Validator

Base32hex validation: the sort-friendly cousin of Base32

Base32hex is the "extended hex" alphabet variant of Base32, standardized in RFC 4648 section 7. It encodes binary data as 32-character text but with a critical twist: the alphabet uses digits 0–9 followed by letters A–V, ordered by their ASCII codepoints. That ordering means that the byte order of the encoded string matches the byte order of the original binary — a property that standard Base32 (which puts A–Z first, then 2–7) does not have.

The full alphabet:

0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V

Note that the first 16 characters (0-9 A-F) coincide exactly with the hexadecimal alphabet — that is the origin of the "hex" in the name. Encoding the byte sequence [0x14, 0xfb] yields CO====== in base32hex (compare to CT7Q==== in standard Base32).

Base32hex vs standard Base32 vs Crockford

• Standard Base32 (RFC 4648 §6) — alphabet A-Z 2-7. Letters first, no sortable property. Used by TOTP secrets, S/MIME, and email-safe encoding.
• Base32hex (RFC 4648 §7) — alphabet 0-9 A-V. Digits first, sortable. Used by DNSSEC NSEC3 records.
• Crockford Base32 — alphabet 0-9 A-Z minus I L O U. Human-friendly (skips visually ambiguous letters), case-insensitive on input. Used by ULID.

The three variants are incompatible — a Base32hex-encoded string fed to a standard Base32 decoder either errors or produces garbage. Always check which variant your library defaults to: Node's Buffer does not include Base32 at all, Python's base64.b32encode is standard and base64.b32hexencode is the hex variant, Go's encoding/base32 exposes HexEncoding as a sibling of StdEncoding.

Padding rules and length

Base32 (both variants) packs 5 bits per character. Because 8-bit bytes don't divide evenly into 5-bit chunks, the output length is a multiple of 8 and is padded with = at the end. The number of padding characters depends on the input length modulo 5:

• 1 byte → 2 chars + 6 padding (==‍====)
• 2 bytes → 4 chars + 4 padding
• 3 bytes → 5 chars + 3 padding
• 4 bytes → 7 chars + 1 padding
• 5 bytes → 8 chars, no padding

The RFC requires padding, but many parsers are tolerant — they will accept unpadded strings and infer length from the character count. Validators should accept both forms unless interoperating with a strict consumer.

Where base32hex is used

The flagship use case is DNSSEC NSEC3 records (RFC 5155): the hashed owner-name labels are emitted in lowercase base32hex specifically because lexicographic order over the encoded labels must match the order of the underlying hashes, so resolvers can find covering NSEC3 records by string comparison. Other applications pick base32hex when they need a case-insensitive, sortable, URL-safe string — for example slug-style IDs in some content-addressed systems, or compact compact tokens that travel inside HTTP headers without case-normalization issues.

Note that base32hex has no built-in checksum. If you need integrity, append an HMAC or CRC32 to the source bytes before encoding.

FAQ

How is base32hex different from standard Base32? Same encoding mechanic (5 bits per char, padding to multiples of 8), only the alphabet differs. Base32hex puts digits first so the encoded string sorts in the same order as the source bytes.

Are base32hex strings sortable? Yes — that is the whole point. Lexicographic comparison of the encoded form gives the same result as memcmp of the original bytes. Standard Base32 does not have this property because A < 2 in ASCII.

Is the = padding mandatory? The RFC says yes; in practice many libraries accept unpadded input. For DNSSEC owner names, padding is omitted by convention. For interoperability with strict parsers, always pad.

Is base32hex case-sensitive? The alphabet contains only uppercase A–V, but per RFC 4648 the decoding step is case-insensitive — lowercase a-v are accepted on input and produce the same bytes.