Skip to content
AZ Tools

Base32 Encoder / Decoder

Encode and decode Base32 (RFC 4648), with standard and base32hex variants — useful for TOTP secrets and Crockford-style IDs.

Output

How to use

  1. Pick encode or decode.
  2. Choose the variant — Standard (TOTP / 2FA) or Hex (Crockford-style).
  3. Toggle padding off if you want a clean output without trailing =.

About this tool

Show

Encode text to Base32 and decode it back, in either RFC 4648 alphabet: the standard one built from A–Z and 2–7, or the extended-hex variant built from 0–9 and A–V. Padding with equals signs is optional. Base32 packs five bytes into eight characters, so it is bulkier than Base64 — about sixty percent larger than the raw bytes rather than thirty-three — and that is the price of an alphabet with no lower case and no characters that get confused when read aloud or copied off a screen. It is why TOTP secrets, onion addresses and DNS labels use it. The extended-hex variant exists because its alphabet is in ascending order, so encoded strings sort in the same order as the bytes behind them.

Frequently asked questions

Why not just use Base64?

Base32 uses only A–Z and 2–7 — case-insensitive and avoids visually confusing characters like 0/O and 1/l. That makes it safer for hand-typed secrets, voice transcripts, and DNS labels.

Is this what TOTP / 2FA apps use?

Yes. The seed string you scan or type into Google Authenticator / Authy / 1Password is Base32-encoded with the standard alphabet. Padding is usually stripped.

What's the difference between Standard and Hex?

Standard (A–Z, 2–7) is the common one. Base32hex (0–9, A–V) preserves the sort order of the original bytes, which matters for things like generated filenames where you want byte-order sorting to match string-order sorting.

Does this work on binary data?

The input field is text — Unicode is encoded as UTF-8 first. For arbitrary binary data, paste the bytes hex-encoded into a separate tool first.

Related tools