Base32 Encoder Decoder
Encode plain text to Base32 and decode it back locally.
Base32 Encoder Decoder
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The Base32 Encoder Decoder converts arbitrary binary data into a text-safe representation using a 32-character alphabet (A–Z and 2–7), and back again. Base32's defining design goal is human-transcription safety: its alphabet deliberately excludes visually similar characters, and because it's fully case-insensitive, it survives being read aloud, hand-copied, or displayed in all-caps without ambiguity in a way Base64 — with its mixed-case, 64-character alphabet — genuinely cannot.
- That tradeoff has a real, practical cost: Base32 output is roughly 60% larger than the equivalent Base64 encoding, because each character carries only 5 bits of information instead of 6. This is exactly the tradeoff at the center of choosing among the base-encoding family covered across this hub — Base32, Base58, Base64, and Base85 all solve the same fundamental problem (representing binary data as text) with different points on the compactness-versus-transcription-safety spectrum, and Base32 sits deliberately toward the safety end.
How It Works
- Input text is first converted to its raw bit sequence (8 bits per character).
- That bit sequence is regrouped into 5-bit chunks — the reason Base32 needs a 32-character alphabet (2^5 = 32) to assign one character per possible chunk value.
- Each 5-bit chunk is mapped to its corresponding character in the Base32 alphabet (A–Z, then 2–7, deliberately skipping 0, 1, 8, and 9 to avoid visual confusion with O, I, B, and g/q in various fonts).
- The output length is padded with = characters to a multiple of 8, per the standard, ensuring encoded output always aligns to a fixed block boundary regardless of the original input length.
Usage
- Paste the text or data you want to encode, or the Base32 string you want to decode.
- Click Encode to convert your input into Base32, or Decode to reverse a Base32 string back to its original content.
- Review the result.
- Copy the output for use in your application, configuration, or shared-secret workflow.
Examples
- Encoding a TOTP shared secret in Base32, matching the convention virtually all authenticator apps expect for manual key entry.
- Encoding a short identifier that needs to be readable and typo-resistant when displayed to a human, such as a manually-entered activation code.
- Decoding a Base32 string found in a QR code payload or configuration file back into its original value.
- Comparing the same input's Base32 and Base64 output side by side to see the concrete size difference between the two encodings.
Real-World Use Cases
- Encoding a shared secret or token in a form that needs to survive manual transcription, being read aloud, or display in an all-caps-only context without introducing ambiguity.
- Generating or decoding TOTP (time-based one-time password) shared secrets, which are conventionally Base32-encoded specifically for this transcription-safety reason.
- Encoding identifiers for systems (like certain DNS record types) that are explicitly case-insensitive, where Base32's case-insensitivity is a functional requirement, not just a convenience.
- Choosing Base32 over Base64 specifically when a human will realistically need to read, type, or verbally confirm the encoded value at some point in its lifecycle.
Best Practices
- Choose Base32 specifically when a human will need to read, type, or verbally relay the encoded value — its transcription safety is the entire reason to accept its larger output size over Base64.
- Use Base32 for shared secrets and tokens meant for manual entry (like TOTP keys), matching the established convention that most authenticator tooling already expects.
- Don't use Base32 as a general-purpose default for binary-to-text encoding where transcription safety isn't actually a requirement — Base64 is more compact and just as widely supported for machine-to-machine use.
- Confirm which specific Base32 variant a target system expects if padding or an extended hex alphabet variant matters for that integration — implementations occasionally differ on padding handling.
Common Mistakes
- Choosing Base32 by default without needing its transcription-safety benefit, accepting a 60% larger output for no actual advantage over Base64 in a machine-to-machine context.
- Assuming Base32 is case-sensitive like Base64 — it isn't; the encoding is designed to be safely uppercased, lowercased, or mixed without changing its meaning.
- Manually typing a Base32 string and mixing up a character the alphabet was specifically designed to avoid confusing (though the risk is much lower than with Base64's full alphabet, it isn't zero if handwriting or unusual fonts are involved).
- Forgetting that Base32 is an encoding for transcription and transport safety, not an encryption scheme — it provides no confidentiality, and anyone can decode it without any secret.
Limitations
- This tool implements standard RFC 4648 Base32 with the standard alphabet and padding; it does not implement the alternate 'base32hex' variant used in some DNSSEC contexts.
- Base32 encoding is not encryption and provides no confidentiality — treat it purely as a text-safe representation, never as a way to protect sensitive data.
- Output is roughly 60% larger than the equivalent Base64 encoding, a real size cost for the transcription-safety benefit it provides.
Technical Reference Guide
- Base32 encoding, including the specific alphabet and padding rules this tool implements, is defined by RFC 4648, Section 6.
- RFC 6238 (TOTP, Time-Based One-Time Password) specifies Base32 as the conventional encoding for the shared secret keys used in two-factor authenticator apps, one of Base32's most common real-world applications.
- The alternate base32hex alphabet (ordered to preserve sort order, used in some DNSSEC contexts) is defined separately within RFC 4648, Section 7, and is not the variant this tool implements.
FAQ
Why is Base32 output so much longer than Base64 for the same input?
Base32 packs only 5 bits of information per character (32 possible characters) versus Base64's 6 bits per character (64 possible characters), so the same data takes roughly 60% more characters to represent in Base32.
Why would I choose Base32 over the more compact Base64?
Transcription safety. Base32's alphabet avoids visually similar characters and is fully case-insensitive, making it much safer for a human to read aloud, hand-copy, or display in all-caps — exactly why TOTP shared secrets conventionally use it.
Is Base32 case-sensitive?
No — that's one of its deliberate design features. Unlike Base64, a Base32 string means the same thing whether typed in uppercase, lowercase, or a mix.
Does Base32 encrypt my data?
No — like all encoding schemes in this hub, Base32 provides no confidentiality. It's a reversible, keyless transformation; anyone can decode it without any secret.
Why do authenticator apps use Base32 for secret keys?
Because RFC 6238 (the TOTP standard) specifies Base32 as the conventional encoding for shared secrets, precisely because users sometimes need to manually type a secret key when a QR code isn't available.
What does the '=' padding at the end of Base32 output mean?
It pads the encoded output to a multiple of 8 characters, a fixed block-alignment requirement of the standard — it carries no information itself and is simply structural padding.
Part of this Developer Hub
This utility is part of our comprehensive Encoding & Conversion topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Encoding & Conversion Lab workshop for complementary engineering workflows.
View all Encoding & Conversion Lab tools