Paste a JWT to inspect its header and payload — decoding happens locally in your browser and the token is never uploaded.
Frequently asked questions
Is my token sent to a server?
Decoding is performed locally in your browser, so the token is not sent to AllDays for decoding. Even so, avoid pasting production access tokens or other sensitive credentials into any website unless you have a specific reason to do so.
Does this verify the signature?
No — and that's deliberate. Verifying a signature requires the secret or public key, which you should never paste into a website. This tool decodes and inspects the header and payload; use your backend to verify signatures.
Why can I read the payload without a key?
Because a JWT payload is only Base64URL-encoded, not encrypted. That's by design — never put secrets in a JWT payload, since anyone holding the token can read it.
What does 'expired' mean here?
If the payload has an exp claim, the tool compares it to the current time and flags whether the token is still valid or has expired. It also reads nbf (not-before) if present.
About JWT decoding
- A JWT has three Base64URL parts: a header (algorithm and type), a payload (the claims), and a signature. This tool decodes the first two and shows the third.
- Decoding is not verifying. Anyone can read a JWT's payload — it is only encoded, not encrypted. The signature is what proves the token wasn't tampered with, and verifying it requires the secret or public key, which should never be pasted into any website.
- Common claims:
sub(subject),iat(issued-at),exp(expiry),nbf(not-before),iss(issuer),aud(audience). Timestamps are shown in your local time. - Everything runs in your browser. Your token is never sent anywhere, so it's safe to inspect real tokens here.
Understanding your results
A JWT has three parts separated by dots: the header (which algorithm signed it), the payload (the claims — who the token is for, what it can do, when it expires), and the signature. The tool shows the header and payload as readable JSON.
The expiry claim is highlighted: you'll see whether the token is still valid or expired, and when. This is usually the single most useful thing when debugging a login problem.
Does this verify the token is genuine?
No. It decodes and displays the contents but cannot check the signature — that must happen on a server with the secret key.
Is my token sent to a server?
No. Decoding happens entirely in your browser.
What does 'expired' mean?
The token's exp claim is a timestamp; once it's passed, the token should no longer be accepted.
A JWT can contain readable claims and can also function as a credential. Do not paste production tokens, API keys, passwords, or other secrets merely to inspect their contents.
The three parts of a token
A JSON Web Token has three sections separated by dots: the header, the payload, and the signature. The header says which algorithm signed the token; the payload carries the claims (who the user is, when the token expires); the signature is what a server uses to check the token wasn't tampered with.
Decoding is not verifying
This tool decodes a token so you can read its header and payload — it does not verify the signature. Decoding only reverses the Base64URL encoding; verifying requires the secret or public key and confirms the token is genuine. Seeing readable contents here says nothing about whether the token is valid or trusted.
Base64URL and readability
The header and payload are Base64URL-encoded, a URL-safe variant of Base64. Because it's only encoding, the contents are not secret — anyone holding the token can read them. That's why the payload should never contain passwords or other sensitive secrets.
Expiry claims
Many tokens include an "exp" claim, a timestamp after which the token should no longer be accepted. Reading it here tells you when a token was meant to expire, though only a verifying server actually enforces it.
Why tokens became self-contained
Web applications increasingly needed to pass claims between systems without storing every piece of session information in one central place. JWT standardized a compact claims format in RFC 7519 in 2015.
Readable does not mean trusted
JWT headers and payloads are encoded, not automatically secret. Decoding them tells you what the token claims; signature verification is a separate step that establishes authenticity.