Base32 Hex Validator

Base32hex (RFC 4648 §7): the order-preserving Base32 alphabet

Base32hex — also called "extended hex" Base32 — is the variant of Base32 defined in RFC 4648 §7. It uses the alphabet 0–9 then A–V (32 symbols), a direct extension of hexadecimal's 0–F. This tool checks that a string contains only valid Base32hex characters (after stripping = padding and upper-casing).

Its defining property is that encoded order matches binary order: because the symbols are assigned in ascending value (0=0, …, V=31), sorting Base32hex strings lexicographically sorts the underlying bytes too. That is exactly why DNSSEC NSEC3 uses Base32hex for hashed owner names.

Base32hex vs standard Base32

• Standard Base32 (RFC 4648 §6): alphabet A–Z then 2–7. Common, but not order-preserving.
• Base32hex (§7): alphabet 0–9 then A–V. Order-preserving, hex-friendly.
• Same math, different table: both pack 5 bits per symbol; only the symbol-to-value mapping differs.

Where it shows up

• DNSSEC NSEC3: hashed names are encoded in Base32hex precisely for sortability.
• Sortable IDs: timestamps/keys where lexical order must equal chronological/byte order.
• Case-insensitive transport: like all Base32, it survives systems that don't preserve case.
• Mock data / testing: validating that a token is well-formed Base32hex before decoding.

Gotchas

• Don't mix alphabets: a standard-Base32 string fed to a Base32hex decoder produces garbage — W–Z exist in §6 but not §7.
• Padding: = pads the final block to a multiple of 8 symbols; strip it before character validation, as this tool does.
• Length must be valid: Base32 lengths come in fixed residues (8,16,32…); an odd length signals truncation.
• Format ≠ decodable: valid characters don't guarantee the bit-length lines up to whole bytes.

FAQ

Why does Base32hex preserve order? Its symbols increase in value across the whole alphabet (0 < 1 < … < V), so ASCII sort order equals numeric value order.

Is it the same as Crockford Base32? No. Crockford also starts at 0–9 but skips I, L, O, U for readability; Base32hex uses a strict contiguous 0–V.

Is it case-sensitive? No — RFC 4648 Base32 is case-insensitive; uppercase is canonical.