When you need to open a token up
- An API keeps returning 401 and you need to tell an expired token from one that never carried the role you assumed.
- Users report being logged out at random and you want to see how long these tokens are actually issued for.
- You are integrating a third-party login and need to know which fields its payload really gives you.
- Front end and back end disagree about time zones and you need that exp value as a readable local timestamp.
- You are doing a security pass and want to check whether your own tokens carry personal data they should not.
The three parts of a JWT
A JWT is three Base64URL segments joined by dots, in the shapexxxxx.yyyyy.zzzzz. The result panel colours those three segments, and this table says what each one is for.
| Part | What it holds | Readable by anyone? |
|---|---|---|
| Header | A JSON object naming the signing algorithm (alg), the token type (typ) and sometimes a key id (kid). | Yes, by anyone holding the token. |
| Payload | A JSON object carrying what the token asserts. Each field is called a claim: who the user is, what they may do, when it expires. | Yes, by anyone holding the token. |
| Signature | A hash of the first two parts plus a secret. It carries no information; its only job is to prove the first two parts were not altered. | No, and it was never meant to be read. |
What the seven registered claims mean
RFC 7519 defines seven standard claims with names short enough to be cryptic the first time. The claims table in the tool prints these explanations next to each field; here is the full set.
| Claim | Full name | Meaning |
|---|---|---|
iss | Issuer | Who issued the token, usually the URL of your auth service. |
sub | Subject | Who the token is about, most often a user id. |
aud | Audience | Which service is meant to accept it. A service receiving someone else’s token should refuse it. |
exp | Expiration Time | From this moment on, a verifier should reject the token. |
nbf | Not Before | Before this moment, the token should not be accepted. |
iat | Issued At | When it was created. Subtract it from exp to get the intended lifetime. |
jti | JWT ID | A unique id for this one token, used for revocation lists and replay protection. |
Why the times need converting, and how
- Those three time claims hold a NumericDate: seconds since 1 January 1970 UTC, not milliseconds. JavaScript’s
Date.now()returns milliseconds, and mixing the two up is off by a factor of 1000. - A raw second count carries no time zone. The tool prints both your machine local time and the ISO 8601 UTC value, so when your logs disagree the offset is visible at a glance.
- Validity comes in four states: valid now, expired, not valid yet (
nbfis still in the future), and no expiry set at all. That last one deserves attention on its own — a token that never expires cannot be taken back once it leaks. - A freshly issued token showing as not-yet-valid usually means server clocks disagree. Most libraries allow a few seconds of leeway; this tool reads the values literally and adds none.
Why sensitive data does not belong in the payload
This is the most common misunderstanding about JWTs: Base64URL is encoding, not encryption. There is no key and nothing to crack — anyone holding the token can turn the payload back into plain JSON exactly as this tool does. The signature protects against the contents being changed, never against them being read.
- Keep national ID numbers, full dates of birth, addresses and phone numbers out of it.
- Never put passwords, API keys for other systems, or any other working credential in there.
- Think twice before adding email addresses and names: tokens end up in server logs, error reporting tools and browser storage, which copies those fields everywhere too.
- Content that genuinely must be hidden needs JWE, an encrypted format, not the JWS handled here.
- Putting only an identifier in the payload and letting the backend look the rest up is the safer pattern.
Which signatures can be verified here
Give it an HMAC secret and it verifies HS256, HS384 andHS512 offline using the browser built-in Web Crypto. The secret never leaves this tab.
- A pass means the token really was signed with that secret and the first two parts are untouched.
- A failure means one of two things: the secret is wrong, or the token was tampered with.
- Some providers show HS256 secrets as Base64-encoded bytes. Treating those as plain text produces a different signature, so tick the Base64 box when that is the case.
- Asymmetric algorithms such as
RS256need a public key, and fetching one means a cross-origin request that CORS usually blocks. They are unsupported here, and no relay server will be added for them.
Does the token you paste leave the browser
No. Decoding, time conversion and HMAC verification all happen in your browser. No request carries the token or the secret anywhere, and neither is written to browser storage, so closing the tab is enough to be rid of them. The exported report deliberately omits the full token, because a report is something you hand to other people and the token is a working credential. See the privacy policy for the details.
Frequently asked questions
- Does the token I paste get sent to a server?
- No. This site has no backend. Decoding, time conversion and signature verification all run in JavaScript inside this tab. To check for yourself, press F12, open the network tab in developer tools and paste a token — no request goes out.
- What is the difference between decoding and verifying?
- Decoding just turns Base64URL back into JSON. Anyone holding the token can do it, and it proves nothing about whether the contents were altered. Verifying recomputes the hash with the secret and compares it, which is what proves the token came from whoever holds that secret and has not been touched since.
- Why can algorithms like RS256 not be verified here?
- The RS, ES and PS families use asymmetric keys, so verification needs the issuer public key, which normally lives at their JWKS URL. Fetching it means a cross-origin request from the browser, and that is usually blocked by CORS. Rather than ship a feature that works only sometimes, this tool supports HMAC only and no relay server will be added for it.
- Why is the exp time hours away from what my backend logs?
- That is a time zone difference, not a miscalculation. JWT times are UTC seconds since 1970 and carry no zone of their own. This tool shows both your machine local time and the ISO 8601 UTC value, so the offset is visible side by side. Also note the unit is seconds, not milliseconds — mixing those up is off by a factor of 1000.
- Can I edit the payload and re-sign it here?
- No, this tool only reads. An edited token has to be re-signed with the original secret before anything will accept it, and that secret should live only on your server, never pasted into a web page.