How is Base32hex different from standard Base32?

Both pack 5 bits per character, but Base32hex uses the alphabet 0 to 9 followed by A to V, whereas standard Base32 uses A to Z then 2 to 7. The hex variant is chosen so that encoded strings keep the same sort order as the binary data they represent.

Why does sort order matter?

Because the alphabet is in ascending byte-value order, sorting the encoded text gives the same sequence as sorting the original bytes. Systems that store or compare encoded keys, such as DNSSEC NSEC3 hashes, depend on this property to walk records in order.

Where is Base32hex actually used?

Its best-known use is DNSSEC NSEC3 records, where ordered hashes of domain names prove that a name does not exist. It also appears in some identifier schemes that want case-insensitive, sortable, URL-safe tokens.

Is the padding the same as standard Base32?

Yes. The equals sign pads the output to a multiple of 8 characters and carries no data. Decoding ignores padding and whitespace, so you can paste wrapped or padded strings directly.

What happens with invalid input when decoding?

Any character outside the 0 to V alphabet is rejected and the tool names the offending character. Because the alphabet stops at V, letters W through Z are invalid here even though they are valid in standard Base32.

What is the Base32Hex Encoder and Decoder?

Encode and decode using the RFC 4648 Base32hex extended-hex alphabet (0-9 then A-V). Unlike standard Base32, encoded output sorts in the same order as the raw bytes, which is why DNSSEC NSEC3 relies on it. Runs in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Base32Hex Encoder and Decoder

Name: Base32Hex Encoder and Decoder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Base32hex is the extended-hex variant of Base32 from RFC 4648. It encodes the same 5-bits-per-character data, but with an alphabet that preserves sort order, which makes it the format behind DNSSEC NSEC3 records and similar order-sensitive keys.

Standard Base32 vs Base32hex — what actually differs

Both encodings pack exactly 5 bits into each ASCII character, producing strings that are 60% larger than their binary source but entirely safe for text contexts. The only difference is the alphabet:

Position	Standard Base32	Base32hex
0–25	A–Z	0–9 (10 chars) then A–V (16 chars)
26–31	2–7	—
Padding	=	=

Standard Base32 starts with letters, which means the encoded bytes 0x00 and 0xFF both encode to strings starting with A and 7 respectively — the sort order of encoded strings does not match the sort order of the raw bytes.

Base32hex starts with digits 0 through 9 and then continues with A through V, exactly mirroring how hexadecimal ordering works. This means if you sort two Base32hex strings lexicographically, the result is the same as sorting the underlying binary values numerically.

How it works

Encoding is identical to standard Base32 except for the symbol table. Bytes are read as a bit stream and chopped into 5-bit groups, each mapped through the extended-hex alphabet:

alphabet = 0123456789ABCDEFGHIJKLMNOPQRSTUV   (index 0..31)
emit one character per 5 bits, zero-fill the last group
pad with '=' to a multiple of 8 characters (optional)

Because index 0 maps to 0 and the values climb monotonically through the digits and then the letters, the lexical order of two encoded strings matches the numeric order of the bytes they encode.

Why DNSSEC NSEC3 requires sort-order preservation

DNSSEC’s NSEC3 record type proves that a domain name does not exist by pointing from one hashed name to the next hashed name in sorted order, covering all names in between. DNS software must be able to walk these hashes in order to verify the proof. If the encoding did not preserve sort order, a DNS resolver would have to decode every hash before it could determine position — defeating the purpose of the compact encoding.

Base32hex was specified in RFC 4648 §7 precisely for this use case: an encoding that is case-insensitive, URL-safe, avoids punctuation that confuses zone files, and sorts correctly. NSEC3 records in every DNSSEC-signed zone you look up use this format.

When to use Base32hex vs. alternatives

Need	Best choice	Reason
Sort-order preserved IDs	Base32hex	Only Base32 variant with this property
DNSSEC compatibility	Base32hex	Mandated by NSEC3 spec
General binary-to-text	Standard Base32	Wider library support
Shortest output	Base64	33% overhead vs. 60%
Fully URL-safe, no padding	Base64url	Compact and URL-friendly

Decoding notes

Any character outside 0–9 and A–V is invalid in Base32hex — specifically, the letters W, X, Y, and Z are invalid here even though they are valid in standard Base32. The decoder names the offending character so you can spot mismatched-alphabet errors quickly.