Ambimat GroupAmbimatAmbiSecureV2XeSIM & eUICCAmbiAutomationEngineering BlogAhmedabad · India · Est. 1982
Encoding utility

Base32 Encoder and Decoder

Encode and decode Base32 and base32hex per RFC 4648. Handles UTF-8 text or raw hex bytes, toggles = padding, and decodes case-insensitively — the shape TOTP / 2FA secrets ship in.

Client-sideRFC 4648TOTP-friendly

How to use this tool

What it does

Encodes and decodes RFC 4648 base32, the alphabet used by TOTP seeds and some provisioning URIs.

When to use it

Use it when handling an authenticator secret or an otpauth URI that stores its key in base32 rather than hex or base64.

Worked example

Decode a TOTP secret like JBSWY3DPEHPK3PXP to recover its raw key bytes.

Input

Result

Type something to convert.
All conversion runs locally in your browser. Nothing is uploaded — safe for TOTP secrets and keys.

What Base32 is for

Base32 turns arbitrary bytes into a 32-character, case-insensitive alphabet so the result survives copy-paste, voice dictation, QR codes, and case-folding transports that mangle Base64. It trades density for robustness: every five bytes become eight characters, a 60% size overhead versus 33% for Base64. That overhead is a fair price wherever a human might read, type, or dictate the value.

The most common place engineers meet Base32 is the shared secret in a TOTP or HOTP authenticator (RFC 6238 / RFC 4226). The otpauth:// URI behind a 2FA QR code stores its secret parameter in Base32 precisely because it is case-insensitive and avoids the +, /, and = characters that complicate URLs. You will also see Base32 in DNS-based systems, NSEC3 hashes, Bitcoin/onion-style addresses, and anywhere a token needs to be read aloud.

Standard Base32 vs base32hex

RFC 4648 defines two alphabets. Standard Base32 (§6) uses A–Z followed by 2–7. The extended-hex variant, base32hex (§7), uses 0–9 followed by A–V; its advantage is that encoded strings sort in the same order as the bytes they represent, which matters for keys in ordered databases such as DNSSEC NSEC3. The two are not interchangeable — decode with the same alphabet you encoded with, or you will get different bytes back.

Base32

Alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ234567. The default for TOTP, RFC 3548 legacy systems, and most 2FA apps.

base32hex

Alphabet 0123456789ABCDEFGHIJKLMNOPQRSTUV. Sort-order-preserving; used by NSEC3 and ordered key stores.

Padding

Trailing = rounds output to a multiple of 8 characters. Optional in practice — TOTP secrets usually omit it. This tool reads either.

Common mistakes

Related tools

Base64

Standard and URL-safe Base64 for the denser cases.

Open Base64 →

ASCII ↔ HEX

Inspect the raw bytes behind a decoded secret.

Open ASCII ↔ HEX →

More utilities

Parsers, decoders, and references for smart-card and FIDO engineers.

All resources →

Frequently asked questions

What is the difference between Base32 and base32hex?

Both are defined in RFC 4648 and map five bits to one printable character. Standard Base32 uses the alphabet A–Z then 2–7. base32hex (the extended-hex alphabet) uses 0–9 then A–V, so the encoded text keeps the same sort order as the underlying bytes. They are not interchangeable: text encoded with one alphabet will decode to different bytes under the other.

Why does my TOTP secret use Base32?

RFC 6238 (TOTP) and RFC 4226 (HOTP) carry the shared secret as Base32 because it is case-insensitive and avoids the +, / and = characters that are awkward in otpauth:// URIs and QR codes. Authenticator apps decode the Base32 secret back to raw bytes before running HMAC. Use this tool to decode a Base32 secret to hex when debugging a one-time-password mismatch.

Is Base32 padding required?

RFC 4648 specifies = padding so that the encoded length is always a multiple of eight characters, but many systems (including most TOTP secrets) drop it. This tool can emit padded or unpadded output and accepts either on decode, ignoring whitespace and case.

Does anything I paste leave my browser?

No. All Base32 encoding and decoding runs locally in JavaScript on this page. Nothing is uploaded, logged, or sent to a server, so it is safe to decode sensitive secrets such as TOTP seeds.

Why use Base32 rather than Base64 for a shared secret?

Base32 uses a case-insensitive alphabet without easily confused characters, so it survives being read aloud, retyped, or printed on a recovery sheet. That robustness matters more than compactness for a secret entered by hand.