How to Decode a JWT (JSON Web Token)

You've got a long string of gibberish that starts with eyJ and you need to know what's inside it. That's a JSON Web Token (JWT) — and the good news is you can read it in about five seconds, because a JWT isn't encrypted. It's just encoded.

Paste it into our free JWT Decoder and you'll instantly see the header and payload as readable JSON. Everything happens in your browser — the token is decoded locally with JavaScript and never uploaded to a server. That matters more than you might think, because a live JWT is a credential: anyone who has it can act as the user it belongs to. Pasting production tokens into a random website that processes them server-side is quietly handing over a key. A client-side decoder removes that risk entirely.

This guide covers how to decode a JWT online or in code, what each part of the token means, how to read the claims (including those cryptic exp timestamps), and the one thing every developer eventually learns the hard way: decoding a JWT is not the same as verifying it.

A JSON Web Token (defined in RFC 7519) is a compact way to pass claims between two parties — most commonly, between an authentication server and an API. It's the backbone of modern login sessions, OAuth flows, and API authentication.

Every JWT is three Base64URL-encoded segments joined by dots:

header.payload.signature

1. Header — metadata about the token itself: the signing algorithm (alg, e.g. HS256 or RS256) and the token type (typ).
2. Payload — the actual claims: who the token is about, who issued it, when it expires, and any custom data (roles, email, permissions).
3. Signature — a cryptographic signature over the first two parts, created with a secret key (HMAC) or private key (RSA/ECDSA). This is what makes the token tamper-evident.

The header and payload are only encoded, not encrypted — Base64URL is a reversible text encoding, not a cipher (our Base64 guide explains the difference in depth). That's why any decoder can read them without knowing any secret. The signature is the only part that requires a key — and it's for verification, not for hiding data.

1. Open the free FileNaut JWT Decoder — no signup, nothing to install.
2. Paste your token into the input box. It should be the full three-part string, dots included.
3. Click Decode.
4. Read the results: the Header panel shows the algorithm and type; the Payload panel shows every claim as formatted JSON.
5. Need the JSON elsewhere? Click Copy JSON to grab the decoded output, then paste it into our JSON Formatter if you want to reformat, minify, or validate it.

The whole process runs locally in your browser tab. Close the tab and nothing persists anywhere.

If you get an "Invalid JWT token" error, check three things: the token has exactly three dot-separated parts (an opaque session ID or an encrypted JWE token won't decode this way), you copied the whole string with no truncation, and there's no surrounding whitespace or a Bearer prefix pasted in with it.

This is the part that trips up almost everyone at first: anyone can decode any JWT. No secret required. If decoding felt like "unlocking" the token, it wasn't — you just reversed a public text encoding.

What you can't do without the key is verify the token — confirm the signature is valid and the contents haven't been tampered with. That's the entire security model:

• Decoding answers: "what does this token claim?" — anyone can do it.
• Verifying answers: "is this claim genuine and untampered?" — only someone with the secret key (HS256) or the issuer's public key (RS256) can do it.

Two practical consequences follow. First, never trust a decoded payload on the server without verifying the signature — an attacker can craft a token claiming to be anyone; the signature check is what catches it. Second, never put secrets in a JWT payload — passwords, API keys, personal data. The payload is readable by anyone who ever sees the token, including everything between your server and the user's browser.

Most JWTs use a handful of standard "registered claims" with three-letter names. Here's the decoder ring:

The time claims (exp, nbf, iat) are Unix timestamps in seconds. To turn 1753380000 into a human date, use our Unix timestamp guide — the short version: it's seconds since January 1, 1970 UTC. If the exp value is in the past, the token is expired and any properly built API will reject it, no matter how valid the signature is.

Anything else in the payload — email, role, permissions, name — is a custom claim the issuing application added. Same rules apply: readable by anyone, trustworthy only after signature verification.

For automated workflows, decoding is a one-liner in most languages. Remember JWTs use Base64URL (with - and _), not standard Base64 (with + and /) — the libraries below handle that for you:

# JavaScript (browser or Node) — decode only, no verification
JSON.parse(atob(token.split('.')[1].replace(/-/g, '+').replace(/_/g, '/')))

# Node.js with verification (the right way on a server)
const jwt = require('jsonwebtoken');
jwt.verify(token, secret);          // throws if invalid or expired

# Python — decode only
import jwt
jwt.decode(token, options={"verify_signature": False})

# Python — with verification
jwt.decode(token, secret, algorithms=["HS256"])

# Command line
echo "$TOKEN" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null | python3 -m json.tool

The pattern to internalize: the decode-only versions are for inspection and debugging. The verify versions are for trusting. On a server, always verify.

• Debugging a 401? Decode the token first. Nine times out of ten the answer is right there: an expired exp, a wrong aud, or a missing role claim.
• Check the alg header when integrating. Your verification code must expect the same algorithm the issuer uses — and should explicitly whitelist it. Accepting whatever the header claims (including none) is a classic vulnerability.
• Keep tokens short-lived. A JWT can't practically be revoked before expiry, so a leaked long-lived token stays dangerous. Short exp plus refresh tokens is the standard pattern.
• Treat every JWT like a password. Don't commit them to repos, paste them into chat tools, or log them. For inspection, use a client-side decoder like ours so the token never leaves your machine.
• Don't confuse JWT with encryption. If you need the payload hidden, you need JWE (encrypted tokens) or transport-level protection — a signed JWT (JWS) hides nothing. For integrity checks on arbitrary data, a hash plays a similar tamper-evidence role.