What's inside a JWT? Decoding vs verifying
What a decoded token tells you, what it never can, and the handful of checks that separate reading a token from trusting it.
Decoding a JWT shows you what it says and proves nothing about whether to trust it. A JSON Web Token has three dot-separated parts: a header, a payload and a signature. The first two are JSON in Base64URL, so anyone can read them, while the signature is what lets the receiving server confirm nobody changed them. The JWT decoder splits a pasted token into its parts, shows expiry dates and warnings, and can check HS256, HS384 and HS512 signatures when you supply the secret, all inside your browser.
Why decoding is not verifying
Anyone holding a token can read it, because Base64URL is an encoding, not encryption. What the signature adds is integrity: the server recomputes it with its key and compares. A token with an invalid signature can still decode into a perfectly believable payload. So treat a decoded token as a description and never as proof.
The format is defined in RFC 7519. If Base64 is new to you, what is Base64 explains why an encoding isn't a lock.
What are the three parts?
| Part | Holds | Readable? |
|---|---|---|
| Header | The signing algorithm (alg) and token type (typ) | Yes, only encoded |
| Payload | The claims, such as who the user is and when the token expires | Yes, only encoded |
| Signature | A fingerprint showing header and payload weren't altered | Binary, not human readable |
The claims to check first
exp: when it expires, in seconds since January 1, 1970.nbf: not valid before this time.iat: when it was issued.iss: who issued it.sub: who it's about, usually a user ID.aud: who it's intended for.
These dates are plain numbers. The decoder converts them and warns you when a token has expired or isn't valid yet. To convert a number yourself, use the timestamp converter, and see Unix timestamps and the 2038 problem for why the format exists.
A quick review routine
- Paste the token into the JWT decoder. If parts are missing, it tells you a JWT needs three.
- Read the header. If
algisnone, the tool flags it as high severity: the token has no signature, so anyone could have forged it. - Check
exp,nbfandissin the payload against what you expect. - If it's an HS256, HS384 or HS512 token and you know the secret, paste it and click Verify. A match shows a valid signature, and a mismatch shows an invalid one. A secret shorter than 32 characters triggers a reminder that short HS256 secrets are easy to brute-force.
Try it with a sample token
This token is a demo. It belongs to no system and was signed with an invented secret:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQyIiwiaXNzIjoiZWplbXBsby50ZXN0IiwiaWF0IjoxNzkwMDAwMDAwLCJleHAiOjE3OTAwMDM2MDB9.h0JpMtcLygUE312VrCShXYpl49a4q6lGtd_1dgjN264Paste it into the decoder. The header reads {"alg":"HS256","typ":"JWT"} and the payload holds sub: user-42, iss: ejemplo.test, iat: 1790000000 and exp: 1790003600. That exp is September 21, 2026 at 15:13 UTC, so the tool flags the token as expired, which is exactly the warning you'd see on a real stale token. Paste secreto-de-ejemplo-de-al-menos-32-caracteres as the secret and click Verify, and the signature comes out valid. Change a single letter of the secret and it turns invalid.
Where local verification stops
The tool checks HMAC-signed tokens (the HS family) that rely on a shared secret. For RSA tokens, such as RS256, it doesn't verify and says so: verify those in your backend with the public key. The tool also verifies only the signature. Whether a token should be accepted still depends on its expiry, issuer and audience, and on your application's rules.
A note on time zones and clocks
The numbers in exp, nbf and iat count seconds from a fixed moment in UTC, so they carry no time zone. Only the display depends on where you are, which is why the same token can look like different local times to two people. A server also compares those values against its own clock, so a machine whose clock is off can reject a fresh token or accept an expired one. When a token fails "for no reason", compare the clocks before anything else.
What should never go in a payload
Since the payload is readable without a key, keep passwords and anything private out of it. And handle a token as a credential: whoever holds it can use it until it expires. Pasting a real production token into a site you don't control is a risk, which is why a tool that processes it locally is the better habit. For that angle in another tool, see the privacy risk of online JSON formatters.
Frequently asked questions
What is a JWT?
A JSON Web Token is a string of three dot-separated parts, header, payload and signature, used to carry verifiable information between systems, such as the identity of an already authenticated user.
Can anyone read a JWT's contents?
Yes. The header and payload are Base64URL-encoded, not encrypted, so anyone with the token can read them. That's why secrets don't belong inside.
Does decoding a JWT prove it's valid?
No. It only shows the contents. Validity depends on verifying the signature with the correct key, and checking the expiry and issuer as well.
What does exp mean in a JWT?
It's the expiration time, in seconds since January 1, 1970. After that moment the token shouldn't be accepted.
What is alg none?
A token declaring no signing algorithm. It carries no signature, so anyone could have made it. A correctly configured server must reject it.
Is my token sent to a server?
No. Reading and verifying happen in your browser.
Decode your JWT locally
Header, payload, expiry and warnings, plus HS256, HS384 and HS512 signature checks. Runs in your browser, free, no signup.
Open JWT Decoder →Related tools
- JWT Decoder: header, payload, expiry and HS256, HS384 and HS512 verification.
- Base64: encode and decode, the basis of each JWT part.
- Timestamp Converter: turn exp, nbf or iat into a readable date.
- JSON Formatter: format the payload to read it more easily.
You might also like: best developer tools 2026, you leaked an API key: the damage control playbook, UUID v4 vs v7: which to use as a database key and Strong password: why length beats complexity.