2026-08-26 · 5 min read · Rahul Chitturi
- base64
- api
Base64 output may be one uninterrupted string or wrapped across lines for MIME transport. Email tooling often inserts line breaks at a fixed width, while JSON APIs and strict decoders may expect no whitespace at all.
The mismatch can corrupt attachments, invalidate request bodies, or produce errors only after a payload crosses a proxy that folds long lines.
Inspect transport before changing the bytes
Keep a known-good binary fixture and compare the encoded value at each boundary. Check whether line feeds are literal characters, escaped sequences, or formatting added only by a viewer.
- Identify whether the source emits MIME-wrapped or continuous Base64
- Confirm whether the decoder ignores ASCII whitespace
- Check JSON, YAML, and environment variable escaping
- Compare decoded hashes instead of visually scanning long strings
Normalize only where the contract allows
Removing whitespace is safe only when it is outside the Base64 alphabet and the field is documented as Base64 data. Do not blindly strip characters from signed messages or compound formats where line endings are meaningful.
For email, follow MIME's wrapping rules. For JSON APIs, prefer an unwrapped string and document the accepted alphabet, padding, and maximum decoded size.
A Flashman workflow
Use the Base64 tool to decode a safe fixture, the diff tool to reveal inserted whitespace, the hash tool to compare decoded bytes, and the URL encoder if the value travels in a query component.
Add a regression test that sends wrapped and unwrapped input according to the documented contract, including the exact newline style seen in production.