Base32 Encoder Decoder
Encode text or hex bytes to Base32 and decode it back, with RFC 4648, Base32hex, Crockford and z-base-32 alphabets and optional padding.
This guide is not yet available in your language and is shown in English.
Tool guide
What this tool does
Base32 Encoder Decoder converts data to and from Base32, the case-insensitive 32-character encoding used for TOTP secrets, onion addresses and human-friendly identifiers. It supports the RFC 4648 standard and hex alphabets, Crockford’s Base32 with its forgiving decoding, and z-base-32.
Base32 encodes binary data using 32 characters, five bits per character. It produces longer output than Base64 (8 characters for every 5 bytes, a 60% increase) but uses only one letter case and avoids symbols, so it survives case-insensitive systems, can be read aloud and typed by hand. That is why authenticator apps store TOTP secrets in Base32, Tor uses it for .onion addresses, and many systems use it for short codes and identifiers.
This tool offers the four alphabets you are likely to meet. RFC 4648 Base32 uses A-Z and 2-7 with “=” padding to a multiple of 8 characters. Base32hex (also RFC 4648) uses 0-9 and A-V and keeps sort order. Crockford’s Base32 drops I, L, O and U to avoid confusion, and its decoder treats O as 0 and I or L as 1 and ignores hyphens. z-base-32 is a lowercase alphabet designed for readability. You can encode UTF-8 text or raw hexadecimal bytes, and decode back to either form, all locally.
How to use Base32 Encoder Decoder
- Enter text, hexadecimal bytes or Base32 data in the Input box.
- Choose “Encode to Base32” or “Decode Base32” under Mode.
- Select the Alphabet used by the system you are working with.
- Set “Plain data format” to UTF-8 text or Hexadecimal bytes.
- Toggle = padding for the RFC 4648 variants, then copy or download the result.
Tips for better results
- TOTP secrets from QR codes are RFC 4648 Base32 without padding; decode them as hex to see the raw key bytes.
- Decoding is case-insensitive for the RFC 4648 and Crockford alphabets, so pasted lowercase secrets work.
- Every 5 input bytes become exactly 8 Base32 characters, which makes padded output length easy to predict.
- Use Crockford’s alphabet for codes that people must read out or type, such as order or licence references.
Common use cases
- Inspecting or re-entering a two-factor authentication secret.
- Generating human-readable IDs that avoid ambiguous characters.
- Decoding Base32 values found in DNS records, such as NSEC3 hashes, which use Base32hex.
- Converting binary keys into a form that is safe in case-insensitive file systems.
Common mistakes to avoid
- Decoding data with the wrong alphabet: the same text decodes to different bytes in RFC 4648 and Base32hex.
- Removing padding when a strict decoder requires it, or adding it where Crockford or z-base-32 never use it.
- Decoding a binary key as UTF-8 text, which triggers an invalid UTF-8 error. Choose the hexadecimal output format instead.
Frequently asked questions
Why use Base32 instead of Base64?
Base32 uses a single letter case and no punctuation, so it is safer for case-insensitive systems, URLs and manual typing. The trade-off is larger output: 160% of the input size compared with 133% for Base64.
What is Crockford’s Base32?
An alphabet by Douglas Crockford that excludes I, L, O and U. When decoding, it accepts lowercase letters, maps O to 0 and I or L to 1, and ignores hyphens, which makes human-entered codes forgiving.
Why does padding appear at the end?
RFC 4648 pads output to a multiple of eight characters with “=”. It lets decoders know the exact length, but many applications, including TOTP apps, omit it.
Feedback & suggestions
Help us improve Base32 Encoder Decoder. We read every message.