2026-08-31 · 6 min read · Rahul Chitturi
- base64
- encoding
- interoperability
Several Base64 strings can appear to decode to the same bytes when a permissive decoder ignores malformed padding or non-zero unused bits. A stricter library may reject the same value after a runtime, gateway, or security-policy upgrade.
Comparing encoded text also becomes unreliable when one producer emits standard Base64, another uses Base64url, and a third removes padding.
Identify the exact encoding profile
Document the alphabet, whether padding is required, and whether whitespace is legal for the protocol. MIME line wrapping, JWT Base64url, and a JSON field carrying standard Base64 are different contracts.
- Reject characters outside the selected alphabet
- Check length and terminal padding before decoding
- Require unused bits in the final quantum to be zero
- Re-encode decoded bytes to test canonical form
Do not normalize signed text blindly
If a signature covers the encoded representation, changing padding, alphabet, whitespace, or letter case changes signed bytes. Verify according to the protocol rather than decoding and reconstructing input first.
At a new API boundary, accept one documented representation and emit one canonical form. Compatibility exceptions should be narrow, measured, and tested.
A Flashman workflow
Use the Base64 tool with public fixtures, diff to compare textual forms, hash tool to confirm decoded byte equality, and JSON formatter to expose escaping or hidden wrapping.
Add fixtures for every remainder length, standard and URL-safe alphabets, missing and excess padding, non-zero pad bits, embedded whitespace, invalid characters, and signed input.