Developer

JWT Decode vs Verify: What's the Difference?

Dev Nexus4 min read

Decoding reads a token's claims; verifying proves they're genuine — mixing them up is how JWT security goes wrong.

"Decode" and "verify" sound interchangeable, and with JWTs that confusion is dangerous. Decoding reads what a token says. Verifying proves the token is genuine. Trusting a decoded claim as if it were verified is one of the most common — and most serious — JWT mistakes.

This post pins down the difference and shows where each step belongs.

The Problem

A JWT's header and payload are only BaseundefinedURL-encoded, so anyone can read them — and anyone can write them. Nothing stops an attacker from crafting a token that says "admin": true or "sub": "someone-else". If your application reads that claim and acts on it without checking the signature, you've handed over the keys.

The trap is that decoding "works": you paste a forged token, the claims decode perfectly, and everything looks fine. Decoding never fails on a forgery, because it never checks authenticity in the first place.

The Solution

The two operations answer different questions.

Decoding BaseundefinedURL-decodes the header and payload so you can read the claims. It needs no key and proves nothing about authenticity. That's what the JWT Decoder does — locally, in your browser, for inspection and debugging.

Verifying recomputes or checks the signature over the header and payload using the matching key: the shared secret for HS256, or the issuer's public key for RS256/ES256. If the signature matches, the token is authentic and unaltered. Verification belongs on your server, in a trusted JWT library — never in a browser tool that has no business holding your keys.

Step-by-Step Guide

1
Decode to inspect
Use decoding when you want to see what's in a token — during debugging, in a bug report, or while building a test fixture. Paste it into the JWT Decoder and read the claims. This is read-only and needs no secret.
2
Verify to trust
Before your application acts on any claim, verify the signature server-side with a vetted library. Only after verification succeeds should you treat sub, scope or roles as trustworthy.
3
Use the right key for the algorithm
For symmetric HS256, the same secret signs and verifies — keep it on the server only. For asymmetric RS256/ES256, a private key signs and the matching public key verifies, so you can distribute the public key safely.
4
Check the standard claims too
A valid signature isn't the whole story. Verification should also confirm exp (not expired), nbf (already valid), and that iss and aud match what your service expects. A good library does this when you configure it.
5
Pin the expected algorithm
Tell your library exactly which algorithm to accept. Never let the token's own header dictate the algorithm unchecked — that's the root of the classic alg: none and RSundefined-to-HSundefined confusion attacks.

Common Mistakes

Trusting decoded claims without verifying
This is the cardinal sin. Decoded claims are unverified input from the client. Anyone can forge them. Always verify the signature before granting access based on a claim.
Accepting alg: none
The none algorithm means "no signature." If your verifier accepts it, an attacker can strip the signature and send any claims they like. Reject none and pin the algorithms you expect.
Confusing the secret and the public key
With RSundefined the private key signs and the public key verifies. A well-known attack tricks a server into verifying an RSundefined token as HSundefined using the public key as the HMAC secret. Enforce the expected algorithm to prevent it. If you're experimenting with signing inputs, a Hash Generator can help you see how HMAC changes with the key.
Verifying in the browser
Verification needs a key, and keys don't belong in client-side code or third-party tools. Decode in the browser for inspection; verify on the server where your secrets live.

Frequently Asked Questions

Does decoding a JWT check if it's valid?

No. Decoding only reads the header and payload. It performs no signature check, so it can't tell you whether a token is authentic, expired or tampered with. That requires verification.

Do I need a key to decode a JWT?

No. The header and payload are Base64URL-encoded, so they decode without any key. A key is only needed to verify the signature or to create a new token.

Where should JWT verification happen?

On the server, inside a trusted JWT library, using the correct secret or public key. Verification requires access to keys, which should never be exposed to the browser or third-party tools.

What is the alg: none attack?

It's an attack where a token declares its algorithm as none, meaning no signature. If a verifier accepts that, an attacker can forge arbitrary claims. Defend against it by pinning the algorithms your server will accept.

Can I verify a token with only its public key?

Yes, for asymmetric algorithms like RS256 or ES256. The private key signs the token and the corresponding public key verifies it, which is why the public key can be shared safely.