JSON Formatter
Pretty-print, validate and minify JSON with precise error positions.
Developer & Security
RFC 4648 Base32, with and without padding, plus Crockford.
| Base32 | Base64 | |
|---|---|---|
| Alphabet | A–Z, 2–7 | A–Z, a–z, 0–9, + / |
| Size overhead | 60% | 33% |
| Case sensitive | No | Yes |
| Safe to dictate | Yes | No |
| URL safe | Yes | Needs a variant |
| Typical use | TOTP secrets, onion addresses | Data URIs, email attachments |
The 60% overhead is the price of the properties above. Where data is transmitted rather than handled by people, Base64 is the better trade; where a human reads, types or dictates it, Base32 is.
Standard Base32 omits 0, 1 and 8 deliberately. Zero and O, one and I and L, eight and B are the classic transcription errors, and the alphabet is designed so none of them can occur.
Crockford’s variant goes further: it also excludes U, to avoid accidental obscenity in generated identifiers, and it decodes O as 0 and I and L as 1 so that human mistakes still resolve correctly.
If people will type your identifiers, Crockford is worth the small incompatibility. If a machine will, use the RFC 4648 standard alphabet, because that is what libraries implement by default.
Base32 encodes five bytes into eight characters. When the input is not a multiple of five bytes the output is padded with = to reach a multiple of eight.
Padding matters only when encoded values are concatenated, which is rare. Many systems — TOTP secrets among them — omit it entirely, and most decoders accept either.
If a decoder rejects your string, stripping or adding padding is the first thing to try.
To eliminate transcription errors. Zero and O, one and I or L, eight and B are the characters people confuse when reading or typing, so the alphabet excludes them by design.
No. It is an encoding, fully reversible by anyone. It provides no confidentiality whatsoever — it exists to make binary data survive text channels and human handling.
It uses 32 symbols instead of 64, so each character carries 5 bits rather than 6. That is 60% overhead against Base64’s 33% — the cost of a case-insensitive, dictation-safe alphabet.
Usually not. It only matters when concatenating encoded values. TOTP secrets typically omit it, and most decoders accept a string either way.
A variant that also excludes U and decodes O as 0 and I and L as 1, so human transcription errors still resolve correctly. Useful for identifiers people will type; less widely implemented than RFC 4648.