How to use Base32 Encode / Decode

Pick Encode or Decode at the top of the tool.
Choose an alphabet — RFC 4648 for most cases (TOTP, geohashes, crypto), RFC 4648-hex for sort-stable keys, or Crockford when humans will type or read the output.
Paste your raw text (Encode mode) or Base32 string (Decode mode) into the left pane.
In Encode mode, toggle "Pad with =" off if the target system rejects trailing padding.
Watch the output pane update live. Press ⌘/Ctrl + Enter to swap modes and feed the last output back as input for a quick round-trip check.
Use Copy output to grab the result, or Share to produce a URL that restores your session.

Base32 Encode / Decode

A client-side utility for converting text to Base32 and back across three alphabets: RFC 4648 standard, RFC 4648 Extended Hex (§7), and Crockford. Paste, pick an alphabet, copy — no sign-up, no uploads, no server round-trip. The transform runs in your browser using native TextEncoder / TextDecoder and continues to work offline once the page is cached.

Why Base32 deserves its own tool

Base32 trades some density for an alphabet that survives human contact. Every character is case-insensitive, none of the characters look alike on a low-resolution screen, and the whole set types cleanly on a phone keyboard. That's why it shows up in TOTP seeds (the strings behind every "scan this QR" flow), in Tor v3 onion addresses, in Nostr event IDs, in geohashes, and in every database that wanted ULID-shaped keys that humans can dictate over the phone.

The three alphabets this tool supports are not interchangeable:

RFC 4648 §6 (standard). The canonical Base32 alphabet: A–Z 2–7. Use this for TOTP / RFC 6238 secrets, Google Authenticator tokens, Nix store path hashes, and anywhere a library documentation says just "Base32".
RFC 4648 §7 (Extended Hex). Alphabet 0–9 A–V. Sort order of the encoded text matches the sort order of the underlying bytes, which is the whole point of using it for database keys or range queries.
Crockford. Alphabet 0–9 A–H J K M N P–T V–Z — excludes I, L, O, U. Meant for strings humans write down or dictate. The decoder additionally folds I → 1, L → 1, and O → 0 so a hand-typed string that "looks right" still parses.

Encode to Base32

Encode mode takes raw text — including emoji, accented Latin, CJK ideographs, and multi-line content — and converts it to a Base32 string. The input is first UTF-8 encoded to bytes, then the bytes are walked as a bit stream, emitting one character per 5 bits against the chosen alphabet. When the final group has fewer than 5 bits left, it is zero-padded; when the output length is not a multiple of 8, = padding is appended per RFC 4648 §6.

Two toggles shape the output:

Alphabet. Pick RFC 4648, RFC 4648-hex, or Crockford depending on where the string is headed.
Pad with =. On by default for spec-conformant output. Turn it off for JWT-style compact encodings, URL fragments, or any target that treats = as a reserved character. The length of the body is still sufficient to decode unambiguously.

Example: encoding foobar with the standard alphabet produces MZXW6YTBOI======. Dropping padding leaves MZXW6YTBOI. Switching to the hex alphabet gives CPNMUOJ1E8======.

Decode from Base32

Decode mode accepts Base32 input in any case, with or without = padding, and with surrounding or embedded whitespace. It maps each character back to a 5-bit value against the selected alphabet, streams the bits into bytes, and UTF-8 decodes the result with fatal: true so invalid UTF-8 surfaces as a typed error instead of being silently replaced with U+FFFD.

Three common decode failures each produce a precise error:

Invalid character. Anything outside the selected alphabet (or a U in Crockford mode, or a 1 in RFC 4648 mode) is reported with the offending character and its position.
Impossible length. Base32 body lengths are always ≡ 0, 2, 4, 5, 7 (mod 8). A remainder of 1, 3, or 6 cannot encode any whole number of bytes and is rejected with a specific error.
Non-UTF-8 payload. If the bytes decoded from the Base32 body are not valid UTF-8, the tool says so rather than silently producing a broken string.

Spec references

RFC 4648 — The Base16, Base32, and Base64 Data Encodings (rfc-editor.org)
Douglas Crockford — Base32 alphabet and check-symbol specification (crockford.com/base32.html)

Related tools

Base64 Encode / Decode — the density-optimized cousin; use when the output won't be typed by humans.
Hex Encode / Decode — the debug-friendly byte dump; use when you want to see exact byte values.
URL Encoder / Decoder — percent-encode characters reserved in query strings and paths.

Frequently asked questions

What is Base32 and when should I use it instead of Base64?

Base32 is a binary-to-text encoding defined in RFC 4648 §6 that maps every 5 bits of input to one of 32 printable characters. It's roughly 20% larger than Base64 but uses a case-insensitive alphabet with no lookalike characters, which makes it safer for filenames, DNS labels, manual typing, voice dictation, and QR codes. One-time password seeds (TOTP / Google Authenticator), onion addresses, and human-readable record IDs all use Base32 for exactly this reason.

What are the three alphabets this tool supports?

RFC 4648 standard Base32 uses A-Z 2-7 and is what TOTP secrets, geohashes, and most crypto libraries emit. RFC 4648 "Extended Hex" Base32 (§7) uses 0-9 A-V, which preserves the sort order of the underlying bytes — useful for database keys that need binary-like ordering in text form. Crockford Base32 excludes the letters I, L, O, U to avoid confusion with the digits 1 and 0 and with profanity, and the decoder folds I/L to 1 and O to 0 so hand-typed strings still parse.

Why does this tool drop the `=` padding only optionally?

RFC 4648 §6 mandates `=` padding so every Base32 string has a length that is a multiple of 8 characters. The padding is recoverable from the body length alone, which is why URL-safe and compact encodings commonly drop it. This tool emits padding by default for spec conformance and offers a "Pad with =" toggle for systems (JWT-style payloads, URL fragments, database keys) where the trailing `=` causes parsing friction. The decoder accepts both padded and unpadded input regardless of the toggle.

Is my input sent to your servers?

No. The entire Base32 encode and decode transform runs locally in your browser using `TextEncoder`, `TextDecoder`, and plain arithmetic on 5-bit groups. There is no encode or decode API endpoint, no analytics on input content, and no third-party script in the chain between your clipboard and the output. The Share button encodes state into the URL fragment (`#…`), which browsers never send to servers by design, so even shared links keep your payload private.