Encoding Tools
Base32 encode & decode.
Convert text or hex bytes to Base32 and back. Choose RFC 4648 Base32, base32hex or Crockford Base32 (with an optional check symbol), and switch padding on or off. Runs in your browser; nothing is sent or stored.
How it works: the bytes are read as a stream of bits and cut into 5-bit groups; each group picks one of 32 symbols. RFC 4648 uses A-Z 2-7 and pads the last 8-character group with =. Example: foobar encodes to MZXW6YTBOI======. base32hex uses 0-9 A-V (foobar gives CPNMUOJ1E8======). Crockford uses 0-9 A-Z without I, L, O, U and has no padding.
Inputs
Result
Enter data and press Run.
Method and limits
RFC 4648. Section 6 defines the standard alphabet and = padding; section 7 defines base32hex; section 10 lists the test vectors this page is checked against (foobar gives MZXW6YTBOI====== and CPNMUOJ1E8======). Source: rfc-editor.org/rfc/rfc4648.
Crockford. Decoding accepts either case, reads I and L as 1 and O as 0, and ignores hyphens. The optional check symbol is the value modulo 37 (37 is the smallest prime above 32), drawn from 0-9 A-Z (without I, L, O, U) then * ~ $ = U. Source: crockford.com/base32.html.
Byte strings and Crockford. Crockford’s text defines encoding a number. Here the bytes are encoded in the same 5-bit symbols (zero-extended on the right, no padding), and the check symbol is computed from the finished symbol string read as a base-32 number. That is a convention for byte data, not something the specification states, so another tool may produce a different check symbol for the same bytes.
Strict decoding. Non-zero unused trailing bits, wrong padding and impossible lengths are rejected, which RFC 4648 section 3.5 permits. A successful check symbol confirms the string was typed or copied without a slip; it is not a security control and says nothing about who produced the string.