2026-07-21 · 5 min read · Rahul Chitturi
- base64
- api
- debugging
Base64 bugs often appear only after data crosses an API boundary. One service emits standard Base64 with plus and slash characters, another expects URL-safe Base64 with dash and underscore, and a proxy or framework decodes part of the value before the application sees it.
Padding makes the failure more confusing. Some decoders require trailing equals signs, some accept omitted padding, and some produce a different error depending on string length.
Identify the variant first
Before changing code, classify the value you actually received. Standard Base64, Base64url, percent-encoded strings, and JWT segments have different rules even though they look similar in logs.
- Look for plus and slash characters versus dash and underscore
- Check whether equals signs were stripped by a query parser or form encoder
- Decode Unicode text as bytes, then verify the expected character encoding
- Keep one known-good fixture for each API field that carries encoded data
Watch query strings and redirects
A plus sign in a query string may become a space in form-style decoding. If an encoded value travels through redirects, analytics parameters, or webhook callbacks, URL encoding may be required around the Base64 value itself.
For JWTs, remember that each segment is Base64url without padding. Do not add standard Base64 assumptions to token debugging unless the library documentation explicitly calls for it.
A Flashman workflow
Use the Base64 tool to test safe encoded fixtures, the URL encoder when values move through query strings, the JWT decoder for token segments, and the diff tool to compare pre- and post-transport values.
Document the final contract in precise terms: alphabet, padding policy, text encoding, URL encoding layer, and whether binary payloads are allowed.