How to Decode a JWT Payload With Base64 (Without a Library)

JSON Web Tokens look opaque until you notice the dots. A compact JWT has three parts: header, payload, and signature, each Base64URL-encoded and joined with period characters. Anyone can decode the header and payload. The signature is what stops casual tampering, and decoding does not check it. That distinction matters every time you paste a token into a tool.

The shape of a JWT

Take a token like header.payload.signature. The middle segment is a JSON object of claims: sub, exp, iat, iss, aud, roles, and whatever else your issuer added. The first segment names the algorithm and type. The third segment is binary signature data encoded as Base64URL; reading it as JSON will fail, and that is expected.

Base64URL is Base64 with + and / replaced by - and _, and with padding = characters often omitted. Browser atob() expects standard Base64 with padding, so a manual decode usually means converting URL-safe characters back and restoring padding before decoding. Libraries hide that step; understanding it helps when you are stuck in a constrained environment.

Decode the payload without a JWT library

1. Split the token on "." and take the second segment (index 1).
2. Replace "-" with "+" and "_" with "/".
3. Pad with "=" until the length is a multiple of 4.
4. Base64-decode the string to UTF-8 text.
5. Parse the text as JSON and read the claims.

In a browser console you can do those steps with atob and JSON.parse after the URL-safe conversion. On the command line, many people use a Base64 decoder after the same character fixes. A dedicated Base64 tool works if you paste only the payload segment, not the entire JWT; decoding the whole dotted string as one blob will produce garbage.

What to look for in the claims

exp and iat are Unix timestamps; convert them to human dates when debugging “token expired” failures. iss and aud tell you who minted the token and which audience it was meant for. Custom claims often carry user ids and roles. If alg in the header is none, or if a token you expected to be RS256 shows HS256, treat that as a security smell and investigate the issuer configuration rather than blindly trusting the payload.

Decoding tells you what the token claims. Only signature verification tells you whether you should believe it.

Safety rules when inspecting tokens

Prefer local, browser-side decoding for production tokens. Pasting live access tokens into a random website can leak session credentials. Prefer redacted fixtures when you share examples. Never treat a decoded payload as authentication proof in your own code: an attacker can forge a payload and attach a junk signature if your app skips verification.

Also remember encrypted JWTs (JWE) are a different story. If you only see five dotted segments or the payload is not readable JSON after Base64URL decode, you may be looking at encrypted content. Standard signed JWTs (JWS) in compact serialization are the three-part tokens this guide covers.

When a library is still the right call

Manual Base64 decode is perfect for debugging claims and teaching how tokens work. Production verification should use a maintained JWT library that checks signatures, algorithm allowlists, expiry, issuer, and audience. Hand-rolling crypto checks is where subtle bugs live. Use decode to understand; use verify to trust.