Base32 Encoder

How to use the Base32 Encoder

1. Pick a direction. Encode turns text into Base32; Decode turns Base32 back into text.
2. Type or paste into the input box — the result updates live with every keystroke.
3. Copy the output, or hit Swap & flip direction to feed the output back through and verify a perfect round trip.

What is Base32, and when do I need it?

Base32 represents arbitrary bytes using only the 32 characters A–Z and 2–7 — no lowercase, no punctuation, no digits that look like letters. That makes it ideal anywhere data must survive human transcription or hostile systems: the secret keys behind authenticator apps (Google Authenticator, Authy) are Base32 strings, as are the info-hashes in magnet links. Compared to Base64, it's ~60% longer but far friendlier to humans and filenames.

Reading Base32 output

Every 5 bytes of input become exactly 8 characters of output. When the input isn't a multiple of 5 bytes, = padding fills the final block: one input byte gives 2 characters + 6 pads (f → MY======), two give 4 + 4, three give 5 + 3, four give 7 + 1. The decoder here accepts missing padding gracefully, but flags misplaced padding, illegal characters (watch out for 0, 1, 8, 9), and non-zero trailing bits — the telltale sign of a typo in the final character.

What is Base32 encoding?

Base32 is a way to represent binary data using only 32 readable characters: A–Z and 2–7. Every 5 bytes of data become 8 characters. It's defined in RFC 4648 and is commonly used for one-time passwords (TOTP secrets), file checksums, and anywhere binary data must survive copy-paste through systems that mangle special characters.

What is the difference between Base32 and Base64?

Base32 uses a 32-character alphabet (A–Z, 2–7) while Base64 uses 64 characters (A–Z, a–z, 0–9, +, /). Base32 output is about 60% longer, but it's case-insensitive-friendly, avoids easily confused characters like 0/O and 1/l, and never needs characters that URLs or filenames treat specially.

Why does Base32 output end with = signs?

The = characters are padding. Base32 works in blocks of 5 bytes (8 characters); when your data isn't a multiple of 5 bytes, padding fills the last block out to 8 characters so decoders know exactly where the data ends. For example, 'f' encodes to 'MY======' and 'foobar' to 'MZXW6YTBOI======'.

Why is there no 0, 1, 8, or 9 in Base32?

Deliberately, to prevent human misreading: 0 looks like O, 1 looks like I or l, and 8/9 look like B/G in some fonts. If you see a 0 or 1 in something claiming to be Base32, it's either a typo or a different encoding.

Does this handle emoji and non-English text?

Yes. Text is converted to UTF-8 bytes before encoding, so emoji, Chinese, Arabic, accented characters — anything Unicode — round-trips exactly.

My Base32 won't decode — what went wrong?

The usual culprits: a 0, 1, 8, or 9 snuck in (not valid Base32 characters), padding in the wrong place or wrong amount, or a typo in the last character. The decoder tells you exactly which problem it found instead of guessing.

Is my text sent anywhere?

No. Encoding and decoding happen entirely in your browser with JavaScript. Nothing is uploaded, stored, or tracked.