Base64, JSON, and JWTs: How to Read Encoded Data

Half of debugging an API is just reading what’s already in front of you — a Base64 blob in a header, a wall of minified JSON, a JWT you need to inspect. Here’s what each of these actually is, how to decode it, and one security habit worth keeping.

Base64 is encoding, not encryption

This trips people up constantly: Base64 hides nothing. It’s a way to represent binary data using 64 safe text characters, so you can stuff an image into a data URI, put binary in a JSON string, or pass credentials in a Basic auth header. Anyone can decode it instantly — it is not a security measure.

You’ll meet it in data URIs (data:image/png;base64,...), Authorization: Basic headers, email attachments, and JWTs (below). Decode or encode it with the Base64 tool — and mind the two gotchas: UTF-8 (naive Base64 mangles non-ASCII text unless it encodes UTF-8 first) and the URL-safe alphabet (which swaps +/ for -_ so the value survives inside a URL).

JSON: the bug is usually a comma

When an API response won’t parse, the fastest fix is to pretty-print it — indentation makes a missing comma, an extra bracket, or a stray trailing comma jump out immediately. The JSON formatter validates as it formats and points at the line and column where parsing broke, which turns “somewhere in these 4,000 characters” into “line 213.” It also minifies, for when you need the compact version back.

JWTs: decoding is not verifying

A JSON Web Token is three Base64url parts separated by dots: a header, a payload of claims, and a signature. Paste one into the JWT decoder and you can instantly read the payload — the exp expiry, iat issued-at, and whatever claims the issuer set.

The critical caveat, in bold because it causes real vulnerabilities: decoding a JWT tells you what it says, not whether it’s true. The signature is what proves the token wasn’t forged, and verifying it requires the issuer’s key — which a decoder doesn’t have. Read the claims to debug; never trust them for authorization without server-side signature verification.

The habit: decode locally

Here’s the security throughline. The tokens and payloads you most need to decode are exactly the ones you shouldn’t paste into a random website — production JWTs, internal API responses, customer data. Many online decoders send what you paste to their servers.

These tools decode entirely in your browser — nothing you paste is transmitted anywhere. That’s not just a privacy nicety; it means you can safely inspect a live session token or a real API payload without leaking it. Make “does this tool run locally?” the first question you ask before pasting anything sensitive into a decoder — and if you can’t tell, assume it doesn’t.

Quick reference

• Unreadable text that’s all letters, digits, +/=? Base64 — decode it, it’s not secret.
• API response won’t parse? Pretty-print the JSON; the formatter names the broken line.
• xxxxx.yyyyy.zzzzz? A JWT — decode the middle part to read claims, but verify the signature server-side before trusting anything.