How to Decode a JWT (Without Breaking Security)

What “decoding” actually means

Decoding a JWT means reading its header and payload, which are just Base64URL-encoded JSON. That is it. It does not verify the signature, and it proves nothing about whether the token is genuine.

Think of decoding as opening an envelope and reading the letter. Verifying is checking the wax seal to confirm it was not swapped. You do the first one constantly while debugging; the second only happens on the server, where the signing key lives.

When decoding is the right tool

You decode a JWT when you want to know what it claims: who the user is, when it expires, which audience it targets. That is enough to debug a login flow, confirm a token has not expired, or check that the issuer is who you expect. It is a read-only inspection, and it is completely safe to do on untrusted input — you are not executing anything.

Decode in the browser

function decodeJwt(token) {
  const [, payload] = token.split('.');
  const b64 = payload.replace(/-/g, '+').replace(/_/g, '/');
  return JSON.parse(atob(b64));
}

console.log(decodeJwt(myToken));

The replace calls turn Base64URL back into standard Base64, which atob understands. Grab the first segment instead of the second if you want the header.

Decode from the command line

If you have a token in your clipboard and a terminal open:

# decode the payload (second segment)
echo "<PAYLOAD>" | tr '_-' '/+' | base64 -d | jq .

tr converts the Base64URL characters back to standard ones, base64 -d decodes, and jq . pretty-prints the JSON so it is readable. Drop the jq part if you just want the raw output.

Decode with a GUI tool

For a one-off look, a JWT decoder in your browser is the fastest path — paste, and the claims appear instantly. The catch is trust: a decoder may send your token to its own backend unless it runs entirely in the page. For anything sensitive, such as a real session token, prefer a local or offline decoder so the token never leaves your machine.

On 51NAV the decoder runs in your browser, so the data you paste is not uploaded anywhere.

What the claims tell you

After decoding, the fields worth checking:

• sub — who the token is about, usually a user ID.
• exp — when it expires, in Unix seconds. Compare it to the current time.
• iss — who issued it. Confirm it is an issuer you expect.
• aud — who it is for. If this is not your service, ignore the token.
• iat / nbf — when it was issued, and the earliest it is valid.

A practical debugging workflow

1. Grab the token from your browser’s dev tools — Application → Cookies or Local Storage.
2. Decode it and check that exp has not passed and sub matches the user you expect.
3. Check iss and aud against your setup.
4. If the data looks right but the server still rejects it, the problem is almost always the signature or the secret/key, not the payload you are looking at.

Common pitfalls

• Assuming a decoded token is valid. It is not, until the signature is verified server-side.
• Pasting a production token into a random online decoder.
• Forgetting that exp is in seconds, not milliseconds like JavaScript’s Date.now().

Decoding vs. verifying, in one line

Decode to read. Verify to trust. The first is a few lines of code; the second requires the signing key and must happen on the server. Do not conflate them — a token that decodes beautifully can still be a forgery.

Decoding proves nothing about authenticity. Only signature verification does.