JSON, Base64 and JWT troubleshooting without exposing secrets

1. Identify the failing layer

Separate transport, HTTP, text encoding, JSON parsing, schema validation, authentication and application behavior. A 401 response is not a JSON syntax error, and a valid JSON document can still violate the endpoint contract.

Capture method, public endpoint shape, status, content type and a sanitized body. Keep authorization headers, cookies, API keys and personal data out of screenshots, tickets and online formatters.

• HTTP status and content type recorded
• Sensitive headers removed
• Body preserved with structure intact
• Expected schema or contract available

2. Validate JSON precisely

JSON permits objects, arrays, strings, numbers, booleans and null. Property names use double quotes; comments and trailing commas are not part of standard JSON. A formatter can expose the failing location but cannot decide whether a field has the correct business meaning.

Watch for numbers that exceed the safe integer range of the consuming language, timestamps without an agreed timezone and strings that contain escaped JSON a second time. Compare a known-good payload with the failing one after normalizing formatting.

3. Treat Base64 as transport encoding

Base64 represents bytes using printable characters. Anyone who receives the value can normally decode it, so never use Base64 as password protection. Standard Base64 and URL-safe Base64 use different characters and padding rules.

Determine the original character encoding before interpreting decoded bytes. A correct Base64 decode can still produce unreadable output when the bytes are compressed, encrypted or not UTF-8 text.

• Variant identified as standard or URL-safe
• Padding handled deliberately
• Original character encoding known
• Decoded value treated as potentially sensitive

4. Inspect JWT structure without trusting it

A compact JWT commonly has header, payload and signature segments. The first two are encoded, not confidential. Decoding reveals claims but does not prove who created the token or whether it was changed.

Verification must enforce an expected algorithm and key, then validate issuer, audience, expiration, not-before and any application-specific claims. Do not accept an algorithm because the token requested it. Avoid pasting production bearer tokens into third-party sites because possession may grant access.

5. Build a safe reproduction

Replace identifiers with synthetic values while preserving types, nesting and boundary conditions. Reduce the request until one difference explains the failure. Include the expected and actual status plus the relevant response fragment.

Re-run locally or in an approved test environment. If a token is required, issue a short-lived test credential with minimal scope. Revoke exposed credentials immediately instead of assuming that deleting a message removed every copy.