Base32 Encoder Decoder

Plain text is first encoded as UTF-8 and then converted to Base32.
0 input chars

Encode and decode Base32 online with 4 variants, file conversion, padding controls, hex output, and local downloads for TOTP secrets, readable IDs, and binary debugging.

Related

What is Base32?

Base32 is a binary-to-text encoding that maps raw bytes to 32 printable characters. The standard form comes from RFC 4648 and uses the alphabet A-Z plus 2-7. Every 5 bits become 1 output character, so the result is usually about 60% larger than the original bytes.

Base32 is not the most compact option, but it works well when you need fewer special characters, case-insensitive handling, or strings that humans may read and type. TOTP secrets, some DNS and configuration values, human-readable activation codes, and compact IDs often use Base32.

Different Base32 variants change the alphabet and error-tolerance rules. This page supports RFC 4648 Base32, Base32hex, Crockford Base32, and z-base-32, with strict validation, padding controls, line wrapping, text and file conversion, and hex inspection so you can verify real payloads without leaving the browser.

Use Cases

  • Validate whether a TOTP or OTP secret is valid standard Base32, or rewrite it into Crockford or z-base-32 for better readability.
  • Convert binary config blobs, certificate fragments, offline activation codes, or resource fingerprints into readable strings without special characters.
  • Debug third-party Base32 values that fail because of missing padding, a wrong variant, or malformed length, especially when you need strict validation.
  • Inspect an unknown Base32 payload as UTF-8 text or hex first, then download the decoded binary if it turns out to be a file instead of plain text.

How to Use

  1. Pick the variant first. If the upstream system says RFC 4648, Base32hex, Crockford, or z-base-32, use that exact variant on both encode and decode.
  2. For encoding, choose text or file input, then decide whether you want padding, lowercase output, and 64, 76, or custom line wrapping.
  3. For decoding, paste the Base32 string and enable strict validation when you want to verify that the length and padding follow the expected rules.
  4. Review the result as text, hex, or a downloaded binary file, depending on whether the payload is human-readable content or raw bytes.

Features

  • Switch between 4 Base32 variants on one page: RFC 4648, Base32hex, Crockford, and z-base-32.
  • Handle both text and files: encode UTF-8 text to Base32 or convert any local file into a Base32 string.
  • Inspect decoded results as UTF-8 text, hex, or a downloadable binary file.
  • Control padding, case, and wrapping: emit = padding, force lowercase, or wrap output at 64, 76, or a custom line width.
  • Run strict validation without leaving the browser: check lengths and padding when you need protocol-grade verification, while keeping all processing local.

Should you use Base32, Base64, or Base58?

All three turn binary data into printable characters, but they solve different workflow problems. Choose based on compatibility, character safety, and output length.

FormatBest forTrade-off
Base32TOTP secrets, readable IDs, and case-insensitive environmentsSafer alphabet and easier manual handling, but longer output than Base64.
Base64General text and file transport, Data URLs, and API payloadsMore compact, but it may include +, /, and =. URL or filename scenarios often need a URL-safe variant.Base64 EncoderBase64 URL Safe
Base58Manually copied addresses, QR payloads, and blockchain-style identifiersAvoids 0/O/I/l confusion, but it is not part of the RFC 4648 family and should not replace Base32 in TOTP or standard protocol flows.Base58 Encoder Decoder

Best Practices

Confirm the variant before you debug anything else

The most common Base32 failure is not the math, but the wrong alphabet. If the upstream system expects Base32hex, Crockford, or z-base-32, standard RFC 4648 output will still look plausible while failing every downstream check.

Switch to hex before assuming the decoded result should be text

A valid Base32 string may decode to certificates, image headers, archives, random key bytes, or any other binary payload. Hex view is the fastest way to decide what kind of data you really have.

Prefer Crockford or z-base-32 for human entry workflows

If people need to type the value by hand, Crockford and z-base-32 are usually easier than strict RFC 4648 Base32. They reduce confusion around characters like O, 0, I, and 1.

Do not force every downstream step to stay in Base32

Many real workflows are easier once you convert the payload to Base64, hex, or the original file. Move to the next format in the toolchain instead of keeping everything as Base32 when the task no longer benefits from it.

Base64 EncoderHex Converter

FAQ

How do I choose between Base32 and Base64?

Choose Base64 when you want the shortest common text form for binary data. Choose Base32 when you need fewer special characters, case-insensitive handling, or a better fit for TOTP secrets and human-readable strings. Base32 is longer, but its alphabet is safer in some workflows.

What is the difference between RFC 4648, Base32hex, Crockford, and z-base-32?

The main difference is the alphabet and the decoding rules. RFC 4648 is the general standard. Base32hex sorts digits first. Crockford is optimized for human entry and accepts O/0 plus I/1/L/1 aliases. z-base-32 favors lowercase, human-friendly strings. Encoding and decoding must use the same variant.

Why do some Base32 strings end with = while others do not?

RFC 4648 Base32 and Base32hex often use = padding to fill the output length. Crockford and z-base-32 usually omit padding. On this page you can decide whether to emit = during encoding, and the decoder can still handle missing padding in relaxed mode.

Why does the decoded output look like gibberish?

The source data may not be UTF-8 text at all. It could be an image, certificate, compressed file, random key material, or any other binary payload. Switch to hex view or download the decoded file instead of treating it as text.

Can this tool encode files to Base32 and restore them later?

Yes. You can upload a local file in encode mode and turn it into Base32. In decode mode you can restore the binary bytes and download the result. That is useful for certificates, small config bundles, key material, and binary test samples.

Is my text or file uploaded to a server?

No. Base32 encoding, decoding, hex inspection, and file downloads all run locally in the browser, so the content does not leave your device.

Troubleshooting

Why does my decoded value not match the third-party result?

Check the variant first. Standard Base32, Base32hex, Crockford, and z-base-32 use different alphabets, so even a few different characters can completely change the decoded bytes.

Why does strict mode report an invalid length?

The input may be missing padding, contain invalid characters, or belong to a different Base32 variant entirely. Try relaxed mode first to inspect the payload, then go back and fix the source string.

Why do I get blank or garbled text after decoding?

The original payload may not be UTF-8 text. Switch to hex view or download the decoded bytes to continue analyzing the binary data.

Glossary

RFC 4648 Base32
The most common standard Base32 variant. It uses the alphabet A-Z and 2-7 and may include = padding.
Base32hex
The hexadecimal-order variant defined by RFC 4648. Its alphabet is 0-9 and A-V, which makes numeric ordering easier.
Crockford Base32
A human-friendly Base32 variant that removes I, L, O, and U, and treats O/0 plus I/1/L/1 as equivalent on decode.
z-base-32
A variant optimized for human input and shorter-looking strings. It defaults to lowercase and usually omits = padding.
padding
Trailing = characters used to round a standard Base32 output to the expected length. Common in RFC 4648 and Base32hex, rare in Crockford and z-base-32.

Quick comparison of 4 Base32 variants

If you are unsure which Base32 flavor you need, start with the alphabet and the typical use case.

VariantAlphabetUses =Typical use
RFC 4648A-Z + 2-7Usually yesTOTP and standard Base32 compatibility
Base32hex0-9 + A-VUsually yesNumeric ordering or protocol fields that expect the hex alphabet
Crockford0-9 + A-Z (without I/L/O/U)Usually noHuman entry, short codes, and typo tolerance
z-base-32ybndrfg8ejkmcpqxot1uwisza345h769Usually noHuman-friendly lowercase strings

Standard Base32 length and padding map

For RFC 4648 Base32 and Base32hex, the number of trailing = characters depends on the input byte count.

Input bytesBase32 charactersTrailing =
126
244
353
471
580

Authoritative References