JWT Decoder
Decode a JSON Web Token to read its header, payload and registered claims, with expiry checked against the current time. Nothing leaves your browser.
Runs entirely in your browser. Your input is never sent to our servers.
Paste a token to inspect its header and claims.
What is JWT?
A JSON Web Token (JWT) is a compact, URL-safe token format that carries a set of claims as JSON, split into three base64url-encoded segments — header, payload and signature — joined by dots.
What this JWT Decoder does
This decoder splits a token into its three segments, base64url-decodes the header and payload, and renders the resulting JSON. It annotates the registered claims defined in RFC 7519, converts the numeric timestamp claims into readable dates, and checksexp and nbf against the current time.
Decoding happens in your browser. This matters more here than for most tools: a JWT is frequently a live credential, and pasting a production token into a service that transmits it to a server hands over whatever access that token grants.
How to use it
- Paste the complete token, including all three segments and both dots.
- Read the header to see the signing algorithm (
alg) and key identifier (kid) if present. - Read the payload for the claims the token asserts.
- Check the expiry badge to see whether the token is currently within its validity window.
Understanding your results
Header — normally alg (the signing algorithm) and typ. A kid tells the verifier which key from a key set to use.
Payload — the claims. Registered claims have defined meanings; everything else is application-specific.
exp, nbf, iat — seconds since the Unix epoch, not milliseconds. A token is valid from nbf until exp.
Signature — shown but not verified, because verification requires the issuer’s secret or public key.
Why this matters
JWTs sit at the centre of most modern authentication flows: OAuth 2.0 access tokens, OpenID Connect ID tokens, session cookies and service-to-service credentials. When something returns 401, being able to read the token quickly answers the first questions — has it expired, is the audience right, does the subject match, is the issuer what you expect.
It is also a review tool. Because the payload is only encoded, not encrypted, anyone holding the token can read every claim in it. Seeing exactly what a token discloses is often the fastest way to notice that it carries more than it should.
Worked examples
Debugging a rejected request. A service returns 401 with no detail. Decoding the token shows exp two hours in the past — the client is not refreshing.
Checking audience. A token works against one API and fails against another. The aud claim names only the first service, and the second correctly rejects a token not intended for it.
Spotting over-disclosure. A token intended to carry a user ID also contains an email address, a full name and an internal role list — all readable by anyone who intercepts it, and by the browser storing it.
Common mistakes
Treating decoding as verification. Decoding proves nothing. Anyone can craft a token with any claims. Only signature verification against a trusted key establishes authenticity.
Accepting alg: none. The specification permits an unsecured JWT with no signature. A verifier that honours the token’s own alg field can be handed a forged token with the signature stripped. Pin the expected algorithm server-side.
Confusing seconds with milliseconds. exp is in seconds. JavaScript’s Date.now() returns milliseconds, and mixing them produces expiry dates in the year 56,000.
Putting secrets in the payload. Base64url is encoding, not encryption. If the content must stay confidential, you need JWE or a different design.
Storing tokens in localStorage without considering XSS. Any injected script can read it. An HttpOnly cookie is not readable from JavaScript.
Technical background
A JWT is a JWS (JSON Web Signature, RFC 7515) in compact serialisation, carrying claims defined by RFC 7519. Each segment is base64url-encoded: the standard base64 alphabet with + and / replaced by- and _, and trailing = padding removed, so the token is safe in URLs and headers without further escaping.
The signature covers the first two segments joined by a dot. HMAC algorithms (HS256) use one shared secret for both signing and verification; asymmetric algorithms (RS256, ES256) sign with a private key and verify with a public one, which is what allows a verifier to validate tokens without being able to mint them.
Limitations
This tool decodes; it does not verify signatures. Verification requires the issuer’s key, and performing it in a browser page would mean handling that key here.
Encrypted tokens (JWE) have five segments and an opaque ciphertext payload. They cannot be read without the decryption key and are not supported.
Frequently asked questions
Is my token sent to your servers?
No. The token is decoded in your browser with JavaScript. It is never transmitted, stored or logged. You can confirm this by opening your browser network tab while using the tool.
Can this tool verify the signature?
No. Verification requires the issuer secret or public key. Decoding tells you what a token claims; only verification tells you whether those claims can be trusted.
Why is the payload readable? Is that a bug?
No. A standard JWT is signed, not encrypted. The signature prevents modification, not reading. Never place confidential data in a JWT payload.
What does "alg: none" mean?
It marks an unsecured JWT with no signature. Historically several libraries accepted these by trusting the token’s own algorithm field, which let attackers strip signatures. Always pin the expected algorithm on the server.
My token is expired but still works. Why?
Some services do not check exp, or allow clock skew. Others validate against a session store rather than the token alone. That is a server-side policy question, not something the token itself decides.
References
Last reviewed