Skip to content
BetterPass logo

Base32 Encode / Decode — RFC 4648, Base32Hex, Crockford & TOTP Secrets

Encode or decode Base32 across three alphabets — RFC 4648, Base32Hex (RFC 4648 §6) and Crockford — with an optional padding toggle, a TOTP/otpauth secret extractor, and file upload.

Result

What is Base32 Encoder / Decoder & TOTP Secret Helper?

Base32 is a binary-to-text encoding that represents data using 32 characters (5 bits per character). Because it is case-insensitive and free of visually ambiguous characters, it is the standard choice for 2FA secrets and human-readable identifiers.

~60% overhead — versus Base64's 33%, because each character carries only 5 bits instead of 6.
Three alphabets — RFC 4648 (A–Z, 2–7), Base32Hex (0–9, A–V) and Crockford (0–9, A–Z minus I/L/O/U).
Case-insensitive & typo-safe — no 0/O or 1/I clashes, so strings are safe to read aloud or type by hand.
Optional padding — output can be padded to 8-character blocks with =, or left unpadded (common for TOTP secrets).
TOTP mode — paste an otpauth:// URI to extract and decode its Base32 secret key.

Zero-Server Tool Data Guarantee

All encoding, decoding, and otpauth:// parsing run locally in your browser. Your text, files, and TOTP secrets never leave your device — no server upload, no logging, no tracking.

How to Use

01

Pick a Mode

Encode turns text or a file into Base32; Decode turns Base32 back into readable text; TOTP Secret extracts a key from an otpauth:// URI.

02

Choose an Alphabet

RFC 4648 (default), Base32Hex (0-9, A-V), or Crockford (0-9, A-Z). The stats bar shows the resulting length.

03

Set Padding

Toggle '=' padding on or off. TOTP secrets and QR payloads are usually left unpadded.

04

Enter Input or Drop a File

Type, paste, or drop a text file (or an otpauth:// URI in TOTP mode). Output updates in real time.

05

Copy

Use the copy button to grab the encoded, decoded, or extracted result.

Common Use Cases

TOTP / Authenticator Secrets

Extract and decode the Base32 secret from an otpauth:// URI for Google Authenticator, Authy, and other 2FA apps.

QR-Code Payloads

Encode compact, case-insensitive data into QR codes where the alphabet must survive manual entry.

Base32Hex Key Identifiers

Use the RFC 4648 §6 alphabet for binary key IDs and DNS-safe identifiers with a natural digit-first sort order.

Crockford License / Invite Codes

Generate human-friendly codes that tolerate O/0 and I/1 transcription mistakes.

Case-Insensitive File Names

Encode binary data as filenames that survive case-folding on Windows and macOS.

Implementation Examples

JavaScriptRFC 4648 (native, no library)
// Generic Base32 encoder — RFC 4648 alphabet, optional padding
const RFC4648 = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ234567';


function base32Encode(bytes, pad = true) {
  if (!bytes.length) return '';
  let out = '', buffer = 0, bits = 0;
  for (let i = 0; i < bytes.length; i++) {
    buffer = (buffer << 8) | bytes[i];
    bits += 8;
    while (bits >= 5) { out += RFC4648[(buffer >>> (bits - 5)) & 31]; bits -= 5; }
  }
  if (bits > 0) out += RFC4648[(buffer << (5 - bits)) & 31];
  if (pad) while (out.length % 8 !== 0) out += '=';
  return out;
}


console.log(base32Encode(new TextEncoder().encode('hello'))); // "NBSWY3DP"
console.log(base32Encode(new TextEncoder().encode('hello'), false)); // "NBSWY3DP" (no pad needed here)

Base32 vs Base64

FeatureBase32Base64
Character setA-Z, 2-7 (32 chars)A-Z, a-z, 0-9, +, / (64 chars)
Case sensitive?NoYes
Overhead~60%33%
Ambiguous charsNone (0/O, 1/I removed)Possible
Padding= (to 8-char blocks)= (to 4-char blocks)
Best for2FA secrets, QR, DNSData transport, embedding

Production Best Practices & Security

Use RFC 4648 Base32 for TOTP secrets — authenticator apps expect the A–Z, 2–7 alphabet, usually unpadded. Why:otpauth:// URIs and authenticator apps store the secret as standard Base32; Base32Hex or Crockford will not be accepted. The TOTP mode here extracts and decodes exactly this.
Use Crockford when humans type it — Crockford removes ambiguous I, L, O and U and accepts 0/O and 1/I/L on input. Why:it maximizes typo tolerance for codes people enter by hand or read aloud.
Use Base32Hex for DNS / binary key IDs — RFC 4648 §6 is used where a hexadecimal ordering is convenient. Why:its digit-first ordering sorts naturally and is the alphabet DNSSEC-style systems often use.
Drop the = padding for URIs and QR codes — most otpauth:// secrets and QR payloads are unpadded. Why:padding is redundant once length is known; omitting it keeps QR codes and URIs shorter.
Decode leniently — accept lowercase, whitespace, and missing padding. Why:users paste secrets with spaces or in lowercase; a tolerant decoder avoids spurious failures.
Prefer Base64 for size-critical transport — Base32 is ~60% overhead vs Base64's 33%. Why:pick Base32 only when case-insensitivity or typo-safety matters more than size.

Frequently Asked Questions

Base32 is a binary-to-text encoding defined in RFC 4648. It uses 32 characters (A-Z and 2-7) to represent binary data, carrying 5 bits per character.

Because it is case-insensitive and excludes visually confusing characters like 0, 1, 8, 9, it is ideal for manual entry, voice communication, and systems that might mangle letter case. The trade-off is size: Base32 has roughly 60% overhead versus Base64's 33%.