Decoding is not verifying, and the difference matters
This is the single most important thing to understand about JWTs. Decoding reads what a token claims about itself. Verifying proves that the claims came from who they say and have not been altered. They are entirely different operations with entirely different security properties.
Decoding needs nothing but the token, which is why any tool can do it and why anyone who intercepts a token can read every claim in it. Verifying needs the signing secret for symmetric algorithms, or the issuer's public key for asymmetric ones — and a browser tool that offered to verify would be asking you to paste a signing secret into a web page, which would hand over the ability to forge tokens for your entire system.
So treat a decoded payload as a claim, never as a fact. If your application makes a decision based on a JWT, that decision must sit behind signature verification on your server.
The claims worth knowing by name
A handful of registered claims appear in almost every token and carry defined meanings. Issuer identifies who created and signed it. Subject identifies who it is about, usually a user. Audience says who it is for — a token issued for one API and presented to another should be rejected, and frequently is not.
The three time claims cause the most confusion. Issued-at records creation, expiry sets the point after which the token must be refused, and not-before sets a start time, which is occasionally used to issue a token in advance. All three are seconds since the Unix epoch, not milliseconds.
Everything else is a custom claim, and their contents are entirely up to whoever issued the token — roles, permissions, tenant identifiers, feature flags. There is no standard, so two systems using the same word can mean different things by it.
What a JWT must never contain
Because the payload is encoded rather than encrypted, anything in it is readable by anyone holding the token. That rules out passwords, card numbers, national identifiers, health information and anything else confidential — and this is not a theoretical concern. Tokens with personal data in the payload turn up regularly in browser local storage, in server logs, and in analytics tools that captured a URL.
Keep tokens small as well. They travel in a header on every request, and a bloated payload full of permissions costs bandwidth on each one. Store an identifier and look up the details server-side rather than carrying everything in the token.
If the contents genuinely must be secret, the answer is an encrypted token — JWE — rather than a signed one. Those have five segments instead of three and cannot be read without the decryption key, which is why this page tells you it cannot decode them rather than failing obscurely.
Failures this page will flag for you
An algorithm of none means the token is unsigned and anyone can forge it. This was a widely exploited vulnerability in early JWT libraries, which would read the algorithm from the token itself and skip verification when it said none — trusting the attacker to specify how carefully to check the attacker's input.
A timestamp written in milliseconds reads as a date tens of thousands of years in the future, which in practice means a token that never expires. It is a security bug wearing the costume of a display bug, and it is common in hand-rolled token issuers.
A token with no expiry claim at all is flagged for the same reason. Long-lived tokens are occasionally a deliberate choice and much more often an oversight, and either way it is worth knowing which you are holding.