Your files never leave your device. All processing happens locally in your browser.
How do I encode or decode Base32 (RFC 4648) in the browser?
Pick Encode or Decode, choose the alphabet (standard A–Z 2–7, or the base32hex 0–9 A–V variant) and, for encoding, whether the input is UTF-8 text or hex. The tool converts live — encoding emits one character per 5 bits with optional “=” padding, decoding is case-insensitive and ignores whitespace — and shows byte/char counts, the raw bytes as hex, and specific errors on bad input. Everything runs locally; nothing is uploaded.
Encode UTF-8 text or hex to Base32; decode Base32 back to text, hex and raw bytes
Both RFC 4648 alphabets: §6 standard (A–Z, 2–7) and §7 extended-hex (0–9, A–V)
Live both ways with specific errors (bad character & position, impossible length) and byte counts
Base32 is encoding, not encryption — it adds no confidentiality; 100% client-side, nothing uploaded
What is
Base32 (RFC 4648)
Base32 is a binary-to-text encoding that represents arbitrary bytes using a 32-character, case-insensitive ASCII subset, packing 5 bits into each character (so the output is 8/5 = 1.6× the input size). RFC 4648 defines two alphabets: the standard set (A–Z and 2–7, omitting the ambiguous 0/O and 1/I/l) and base32hex (0–9 then A–V), which preserves the sort order of the underlying bytes. Optional “=” padding aligns the output to a multiple of 8 characters. Base32 is an encoding for safe transport and human handling — used by TOTP/2FA secrets and Tor onion addresses — not encryption: it provides no confidentiality and is trivially reversible.
No. Base32 is a reversible encoding with no confidentiality — anyone can decode it in one step.
Base32 is a binary-to-text <em>encoding</em>, in the same family as Base64 and hexadecimal — it re-expresses bytes as a case-insensitive ASCII subset so they can be typed, read aloud, put in a URL or packed into a QR code. It provides <strong>no encryption, no integrity and no compression</strong>: the transform is public and trivially reversible, so a Base32 string is exactly as secret as the raw bytes. Never use Base32 to protect a password or key. If you need confidentiality, encrypt the data first (for example with AES-GCM) and only then Base32-encode the ciphertext if you need it to be text-safe.
Use Base32 when a value must be typed, dictated or scanned by humans; use Base64 when compactness matters most.
Base32 uses only 32 case-insensitive characters and deliberately drops the look-alikes 0/O and 1/I/l, so it survives being typed by hand, read over the phone or scanned from a QR code with far fewer transcription errors — which is why <strong>TOTP/2FA secrets</strong> (RFC 4226 / 6238) and <strong>Tor v3 onion addresses</strong> use it. Base64 packs 6 bits per character instead of 5, so it is more compact (~1.33× the raw size versus Base32’s ~1.6×), but it is case-sensitive and uses + and / which are awkward in URLs and human input. Rule of thumb: Base64 for machine-to-machine payloads where size matters, Base32 for anything a person has to handle.
They use different alphabets: standard is A–Z then 2–7; base32hex is 0–9 then A–V and keeps the byte sort order.
Both are defined by RFC 4648 and encode 5 bits per character, but they map those 5-bit values to different symbols. The standard alphabet (§6) is A–Z followed by the digits 2–7. The extended-hex alphabet (§7), “base32hex”, is 0–9 followed by A–V — its first sixteen symbols match hexadecimal, and because the symbols are in ascending value order, sorting the encoded strings sorts the underlying data the same way, which is why DNSSEC NSEC3 uses it. The two are not interchangeable: decode with the same variant you encoded with, or you will get different bytes. This tool lets you pick either alphabet for both directions.
Because a TOTP secret is random binary key bytes, not text — read them as hex, not as UTF-8.
A TOTP/2FA secret is a random binary key that happens to be <em>written</em> in Base32 so you can type it into an authenticator app; the underlying bytes are not meaningful text. When you decode it here, the tool shows the raw bytes as <strong>hex</strong> and flags that the result is not valid UTF-8, so you should read the hex rather than the garbled “text” view. This is expected and correct. The tool decodes the secret entirely on your device, so pasting it here does not expose it — but you should still treat a real 2FA secret as sensitive and avoid entering it anywhere you do not trust.
Detailed Explanation
📖How It Works
What the Base32 Encoder / Decoder Does
The Base32 Encoder / Decoder is a 100% client-side tool that implements RFC 4648 exactly. In Encode mode the user supplies UTF-8 text or a hex string and the tool produces a Base32 string; in Decode mode it takes a Base32 string and returns the original text, the raw bytes as hex, and byte counts. Both RFC 4648 alphabets are available — the standard set (A–Z, 2–7) and the extended-hex "base32hex" set (0–9, A–V) — with a padding toggle for the "=" character. Conversion is live in both directions, decoding is case-insensitive and ignores whitespace and newlines, and errors are specific (the offending character and its position, or a length that no valid Base32 encoder could produce). All work happens in the browser and nothing is uploaded.
Encodes UTF-8 text or hex to Base32; decodes Base32 to text, hex and raw bytes
Both alphabets: RFC 4648 §6 standard (A–Z, 2–7) and §7 base32hex (0–9, A–V)
Padding "=" toggle; decode is case-insensitive and ignores whitespace/newlines
Live both ways with byte/char counts and non-UTF-8 detection on decode
Specific errors: invalid character with position, and impossible-length detection
⚙️Methodology
How the Encoding Works
Base32 treats the input as a continuous stream of bits. Encoding reads the bytes most-significant-bit first, emitting one alphabet character for every 5 bits (2^5 = 32 symbols); the final partial group is padded on the low end with zero bits, and if padding is enabled, "=" characters are appended until the length is a multiple of 8. A pure engine (base32Engine.ts) does this with a small bit accumulator, masking the buffer to the leftover bits after each character so it never overflows a 31-bit integer. Decoding reverses the process: it strips whitespace, validates that "=" appears only as a trailing run, rejects final-group lengths of 1, 3 or 6 (which no valid encoder emits), looks up each character in the chosen alphabet, and re-packs the 5-bit values into 8-bit bytes. Text is handled with the browser TextEncoder/TextDecoder so Unicode and emoji round-trip correctly, and hex is parsed tolerantly (optional 0x, spaces, colons or dashes).
Encodes 5 bits per character, MSB-first; output is 8/5 = 1.6× the input size
Optional "=" padding aligns the output to a multiple of 8 characters
Bit accumulator is masked each step so it never overflows a 31-bit int
UTF-8 via TextEncoder/TextDecoder; hex parsing tolerates 0x and separators
📋Use Cases
Where Base32 Is Actually Used
Base32 is chosen wherever encoded bytes must be handled by humans. TOTP/2FA secrets (RFC 4226 HOTP and RFC 6238 TOTP) are distributed as Base32 strings because someone often has to type the seed into an authenticator app from a fallback screen, and the alphabet — which omits the look-alike 0/O and 1/I/l and is case-insensitive — minimises transcription errors; it also fits entirely inside the QR-code alphanumeric subset, so the same secret packs into a smaller, more scannable QR than Base64 would. Tor v3 onion addresses are the Base32 of the service public key, a checksum and a version byte. DNSSEC NSEC3 uses base32hex because its sort order matches the underlying hashes. Some case-insensitive file systems and volume identifiers use Base32 for the same readability reasons. This tool can decode a pasted TOTP secret to inspect its raw key bytes, entirely offline.
TOTP/2FA secrets (RFC 4226 / 6238) are Base32 for easy typing and QR packing
Base32 alphabet drops ambiguous 0/O and 1/I/l and is case-insensitive
Tor v3 onion addresses are Base32(pubkey ‖ checksum ‖ version)
DNSSEC NSEC3 uses base32hex so encoded order matches byte order
A decoded TOTP secret is random key bytes — read them as hex, not text
⚠️Limitations
Honest Limitations
Base32 is an encoding, not encryption, compression or a checksum. It is fully reversible with a public algorithm, so it provides no confidentiality: a Base32 string is exactly as secret as the bytes inside it, and anyone can decode it in one step. Never use Base32 to "hide" a password or key — if you need confidentiality, encrypt first (for example AES-GCM) and only then encode the ciphertext. It is also not compact: Base32 output is about 1.6× the raw size, versus roughly 1.33× for Base64, so prefer Base64 for machine-to-machine payloads where size matters. Two further gotchas: the standard and base32hex alphabets are not interchangeable — decode with the same variant you encoded with — and this tool decodes leniently (accepting missing padding and stray whitespace and not rejecting non-zero trailing bits) to be forgiving of real-world input, so it will read some technically non-canonical strings that a strict RFC 4648 decoder would reject.
No confidentiality, integrity or compression — trivially reversible
Never encode a secret expecting protection; encrypt first, then encode
Base32 is ~1.6× the raw size vs Base64’s ~1.33× — Base64 is more compact
Standard and base32hex are different alphabets; use the same one to round-trip
Decoding is deliberately lenient (padding/whitespace/trailing bits) — not strict-canonical
🔒Privacy & Security
Private by Design
Everything happens on your device. The conversion uses the browser’s built-in TextEncoder/TextDecoder and pure bit-level JavaScript — there is no network request, no upload, no logging, no server and no CDN in the processing path. This is especially relevant here because Base32 is the format of TOTP/2FA secrets: a secret you paste to decode never leaves the page. Nothing is persisted or added to history; reload the tab and your input and output are gone. The tool works offline once cached, supports dark mode and a mobile-first responsive layout, has no analytics or telemetry, and the only optional network use anywhere on the site is consent-gated ads, which never see your input.
Conversion is local via TextEncoder/TextDecoder — nothing uploaded
No server, no CDN, no logging, no telemetry, no account
A pasted TOTP/2FA secret is decoded entirely in the browser
Nothing persisted; input and output vanish on reload
Works offline once cached; dark-mode and mobile-first
Binary-to-text encodings compared
Encoding
Alphabet size
Size overhead
Best for
Base32 (RFC 4648 §6)
32 (A–Z, 2–7)
~1.6× (8/5)
TOTP/2FA secrets, onion addresses — human-typed & QR
base32hex (RFC 4648 §7)
32 (0–9, A–V)
~1.6× (8/5)
DNSSEC NSEC3 — preserves byte sort order
Base64 (RFC 4648 §4)
64 (A–Z a–z 0–9 + /)
~1.33× (4/3)
Compact machine-to-machine payloads
Base16 / hex
16 (0–9, A–F)
2× (2 chars/byte)
Debugging, checksums, byte dumps
Encryption (e.g. AES-GCM)
n/a
varies
Actual confidentiality — encoding never provides this
Base32, base32hex, Base64 and hex are all reversible ENCODINGS and provide no confidentiality; to protect data you must encrypt it. Everything in this tool runs locally in the browser; nothing is uploaded. As of July 2026.
