About

This is not just a converter; it is a comprehensive environment for handling Base32 encoding standards across legacy systems, blockchain addresses, and modern OTP (One-Time Password) implementations. While Base64 is the standard for data density, Base32 is the standard for human reliability and filesystem safety. It eliminates case sensitivity and removes visually ambiguous characters (like 'l', '1', 'I'), making it the superior choice for manual code entry and case-insensitive file systems.

We have engineered this tool to handle the fragmentation of Base32 variants. Whether you are debugging a Geohash coordinate, implementing a custom z-base-32 protocol, or generating TOTP secrets, this engine guarantees bit-perfect accuracy. It operates entirely within your browser's Sandbox, meaning your private keys, binaries, and secrets never touch a server. The interface includes real-time bitwise visualization, file integrity checksums, and a smart "fuzzy decode" mode that attempts to repair broken input strings automatically.

Formulas

The core mechanism of Base32 involves re-grouping binary data. A standard byte consists of 8 bits. Base32 characters represent 5 bits each (2⁵ = 32). The Least Common Multiple of 8 and 5 is 40 bits.

Encoding Process (The 40-bit Quantum):

1. Take a block of 5 bytes: Input = [b₀, b₁, b₂, b₃, b₄]

2. Concatenate into a 40-bit integer N:

N = 4∑i=0 (b_i ⋅ 2^8(4-i))

3. Extract 8 indices (idx₀...idx₇) of 5 bits each:

idx_k = (N >> 5(7-k)) ∧ 0x1F

4. Map indices to the alphabet A:

Output_k = A[idx_k]

If the input bytes are not a multiple of 5, the final block is zero-padded on the right. The number of padding characters (=) added is determined by: ceil(input_len % 5).

Reference Data

Standard / Variant	Alphabet Character Set	Case Sensitive?	Padding	Primary Application
RFC 4648 (Standard)	A-Z, 2-7	FALSE	=	DNSSEC, TOTP (Google Authenticator), MIME.
Base32Hex (RFC 4648)	0-9, A-V	FALSE	=	Legacy sorting systems (preserves sort order).
Crockford's Base32	0-9, A-Z (No I, L, O, U)	FALSE	NULL	Human entry, serial numbers, avoiding profanity.
z-base-32	ybndrfg8ejkmcpqxot1uwisza345h769	FALSE	NULL	Peer-to-peer software, ZRTP, human ease of use.
Geohash	0-9, b-z (No a, i, l, o)	FALSE	NULL	Spatial indexing, map coordinates, location hashing.
Word-Safe	23456789CFGHJMPQRVWX...	FALSE	NULL	Generated IDs that avoid accidental English words.
Electrum (Bitcoin)	qpzry9x8gf2tvdw0s3jn54khce6mua7l	FALSE	NULL	Bitcoin SegWit addresses (Bech32).
Base32-Lakhani	0-9, A-Z (No I, O)	FALSE	NULL	Specific proprietary legacy systems.

Frequently Asked Questions

This almost always happens because the wrong "Variant" was selected. If you encode data with "Base32Hex" but try to decode it with "RFC 4648", the bit mapping will be completely wrong. Ensure the variant matches the source. Also, check if the input string contains hidden non-printing characters or newlines.

Fuzzy Decode uses heuristic logic to repair common user errors. 1) It removes all whitespace, dashes, and invisible Unicode markers. 2) In Crockford mode, it automatically substitutes ambiguous characters (e.g., replaces "I" or "L" with "1", and "O" with '0'). 3) It normalizes case to match the selected alphabet.

Yes. Google Authenticator secrets are standard RFC 4648 Base32 strings without padding. Select "RFC 4648" from the dropdown. If your key has spaces (e.g., 'AAAA BBBB'), enable the "Sanitize/Fuzzy" option to strip them automatically.

Base32 is approximately 60% larger than the original binary data. The ratio is 8:5 (8 output characters for every 5 input bytes). Compare this to Base64, which is only ~33% larger (4 chars for 3 bytes). You trade storage efficiency for case-insensitivity and human readability.

Technically, yes, but browser memory limits apply. We stream the file in chunks, but the resulting Base32 string (which is 60% larger) must eventually fit in the DOM or clipboard memory. For best performance, keep files under 200MB. Larger files will be processed, but copying the text might freeze the browser temporarily.