Security Runs locally Ready to use Built-in examples No tracking

Base32 Encoder / Decoder

Turn text into Base32 (A-Z plus 2-7) or decode Base32 back to text. Authenticator secrets use this format, so decoding stays tolerant: lowercase, spaces, hyphens and padding are all accepted.

Base32 reduces data to the 32 characters A–Z plus 2–7: all uppercase, with none of 0, 1, 8 or 9, so it survives being written down by hand or read aloud. Authenticator secrets and the activation codes of some software use exactly this format. This tool converts both ways per RFC 4648 and prints the encoded result in groups of eight, which keeps transcription from slipping a position.

It runs about 60% longer than Base64, and what that buys is hand-copyability — a trade-off that depends on whether a human or a machine is reading it. Decoding is tolerant: lowercase, spaces, hyphens and padding are all accepted. A character outside the alphabet is an outright error (a 0, 1, 8 or 9 means it was mis-copied) and nothing is guessed or silently corrected. Encoding is not encryption: anyone holding the string can reverse it.

—

—
—

How to use

  1. Paste the text to encode, or the Base32 string to decode.
  2. Choose the direction.
  3. Read the result, grouped in eights for hand copying.
  4. Remember decoding tolerates lowercase and separators, but not wrong characters.

How it works

Basic usage

Pick a direction, then enter content: encoding produces the Base32 string, plus an "8-characters-per-group" layout that's hard to misalign when copying by hand; decoding restores the original text. The copy button beside the main result grabs the complete paste-ready value.

Why Base32 is longer than Base64

Base32's alphabet has only 32 symbols (A–Z plus 2–7), carrying 5 bits per character; Base64 uses 64 symbols at 6 bits each. For the same data Base32 runs about 60% longer — the price of "all uppercase, no confusable symbols, hand-copyable". That's why two-factor keys and activation codes, which humans must type, use it.

What decode errors usually mean

Base32's alphabet omits 0, 1, 8 and 9 (only 2–7 appear), so a mixed-up O/0 or I/1 is usually visible at a glance. The other common issue is length: results are multiples of 8 characters, padded with =, and a wrong length can't decode. This tool automatically ignores spaces, hyphens and padding, and accepts lowercase input.

Method: the RFC 4648 Base32 alphabet (A–Z and 2–7). The input is converted to UTF-8 bytes and encoded five bits at a time, padded with = to a multiple of eight. Decoding tolerates lower case, spaces, hyphens and padding, and reports a hard error on any character outside the alphabet rather than guessing.

Code example

Python Supported directly by the standard library 

import base64

base64.b32encode(b"hello")     # b"NBSWY3DP"
base64.b32decode("NBSWY3DP")   # b"hello"

# Encode non-ASCII as UTF-8 first — a CJK character takes about 3 bytes, so the output gets noticeably longer

Shell Converting on the command line 

echo -n "hello" | base32        # Linux (ships with GNU coreutils)
echo "NBSWY3DP" | base32 -d     # decode

# macOS has no built-in base32; install the GNU version:
# brew install coreutils, then use gbase32

FAQ

Base32 vs. Base64 — what's the difference?

Base64 uses 64 symbols (mixed case plus + and /) at 6 bits per character, inflating data by only about a third — but the mixed case and symbols make transcription and dictation error-prone. Base32 uses 32 symbols, all uppercase, with no 0/1/8/9, costing about 60% extra in exchange for hand-copyability — exactly the two-factor-key use case.

Why are two-factor keys always written in Base32?

2FA keys must be copied into authenticator apps by hand and sometimes read out over the phone, so mixed case and look-alikes like 0/O and 1/I/l must be avoided. Base32's alphabet — all uppercase, only 2–7 and A–Z — minimizes copying and hearing errors.

The decoder reports invalid characters — what's wrong?

Most often the input contains 0, 1, 8, 9 or symbols beyond spaces — none exist in Base32's alphabet. Next, the length: valid input is a multiple of 8 (padded with =). Another classic: pasting a Base64 string into a Base32 decoder — different alphabets, no mutual recognition.

Do the grouped spaces affect copying?

No. Grouping is for human eyes: copying with the spaces included still works, since decoding ignores spaces, hyphens and padding. When pasting into a config file (like a Base32 key), prefer the continuous form in the main result.

Do Chinese characters and emoji encode much longer?

Yes. Text is converted to UTF-8 bytes first: a Chinese character is typically 3 bytes, an emoji 4, while an English letter is 1 — so Chinese content grows noticeably more. For example, two Chinese characters are 6 bytes, encoding to 10 characters (4S62BZNFXU).

Can Base32 serve as encryption?

No. Encoding is just another notation — anyone with the string can restore it in one click; it provides zero confidentiality. Don't rely on Base32 to hide keys or passwords; real protection means an encryption algorithm (like AES) with the key kept safe. This tool deliberately avoids any "encryption" wording.

Why does the decoded text contain garbage blocks?

It means this Base32 wasn't the encoding of any text but of binary data — a fragment of an image, archive or random bytes. Those bytes don't map to legal UTF-8 characters and display as replacement symbols. The byte count below the result confirms how many bytes the original held.

Will the conversion send my key to a server?

No. Encoding and decoding happen inside the browser; the input never reaches a server and is never written to localStorage. This tool has no history section precisely because inputs often contain two-factor keys.