Base32 to Hex Converter
Decode an RFC 4648 Base32 string — like a TOTP 2FA secret or Crockford-style ID — back into its raw hex bytes, padding handled automatically.
How Base32 to Hex Decoding Works
Reverse the encoding process: look up each Base32 character's 5-bit value, concatenate all the bits into one long string, then split that into 8-bit bytes and write each as 2 hex digits. Any = padding characters are dropped first since they carry no data.
Base32 to Hex Example, Step by Step
JBSWY3DP = 48656C6C6F
JBSWY3DP (Base32) = 48656C6C6F (hex, the ASCII text "Hello")
8 Base32 characters = 40 bits 40 bits / 8 = exactly 5 bytes No padding to strip
| Step | Description | Result |
|---|---|---|
| Decode each character | look up each letter's 5-bit value | 40 bits total |
| Regroup into bytes | 40 bits / 8 = 5 bytes evenly | 5 bytes |
| Write as hex | each byte becomes 2 hex digits | 48656C6C6F |
This decodes back to the exact same bytes used in the Hex to Base32 example — encoding and decoding are inverses of each other.
Where Decoding Base32 Actually Comes Up
Verifying a TOTP Secret's Raw Key
Two-factor authenticator apps store secrets as Base32 — decoding to hex confirms the actual key bytes match what your server generated, useful when debugging a setup that isn't working.
JBSWY3DP -> raw key bytes
Inspecting a Crockford-Style Identifier
Short human-typeable IDs (like those used in some URL shorteners and database keys) often encode raw bytes as Base32 — decoding reveals the underlying value being referenced.
Base32 ID -> hex bytes
Debugging a Malformed Base32 String
When a Base32 value fails to decode elsewhere, running it through here with clear error flagging pinpoints whether the problem is invalid characters or incorrect padding.
invalid input -> flagged error
Common Mistakes When Decoding Base32
- Typing 0, 1, 8, or 9 by mistake — standard Base32 doesn't include those characters.
- Forgetting the input length must be a multiple of 8 characters, including any = padding.
- Confusing this with decoding a Base36 or Base64 value, which use different alphabets and grouping.
Why Use This Calculator Instead of Doing It by Hand
- Handles padding and bit regrouping automatically, no manual bit math
- Runs entirely in your browser — nothing you type gets sent anywhere
- Flags invalid characters and lengths instead of returning garbage bytes
- Normalizes case before decoding, since Base32 letters aren't case-sensitive
Frequently Asked Questions
How do you decode Base32 back to hex?
Map each Base32 character back to its 5-bit value, concatenate all the bits, then regroup them into 8-bit bytes and write each byte as 2 hex digits.
Why would I decode a Base32 string to hex?
To inspect the raw bytes behind a TOTP secret key, verify a Crockford-style ID against its underlying value, or feed the bytes into hex-based tooling.
Does this tool accept lowercase Base32?
Yes — it's normalized to uppercase before decoding, since Base32 letters aren't case-sensitive.
What do the = characters at the end mean?
Padding, added during encoding to round the output to a multiple of 8 characters — they're stripped automatically before decoding and don't affect the result.
What happens if I enter an invalid Base32 string?
The calculator flags it — Base32 only uses A-Z and 2-7 (plus = padding), and its length must be a multiple of 8 characters.
Is this the same as decoding Base36?
No — Base36 decodes to a single number. This decodes RFC 4648 Base32 back into raw bytes, a completely different process.
Can I verify a TOTP secret's raw bytes with this?
Yes — decoding the Base32 secret your authenticator app stores reveals the underlying key bytes in hex, useful for confirming two systems were provisioned with the exact same secret.
Why might a Crockford Base32 ID look different from RFC 4648 Base32 once decoded?
Crockford's variant uses a similar but distinct alphabet with built-in checksum characters — decoding a Crockford ID as standard RFC 4648 Base32 here can produce wrong bytes if the alphabets don't match exactly.