Skip to content

JWT Decoder

Paste a JSON Web Token and read its header, payload and signature instantly. Translates the iat, nbf and exp timestamps into readable dates, warns when a token is expired or uses alg: none, and detects when what you have is actually an encrypted JWE.

  • Decoding happens entirely in the browser
  • Header, payload and signature in separate panels
  • Human dates for iat, nbf and exp
  • Expired-token and alg: none warnings
  • Detects JWE (5 segments)
  • Copy JSON or the raw segment

Decoder

Your token never leaves the browser

A leading Bearer prefix is accepted. Decoding runs as you type.

Paste a token of three dot-separated segments and its header, payload and signature will appear here.

No token handy? Load the example — it is synthetic and authenticates nothing.

How to decode a JWT

  1. 01

    Copy the token

    Copy the full JWT from your HTTP client, your logs or the Authorization header. A leading "Bearer " prefix is stripped automatically.

  2. 02

    Paste it into the decoder

    Paste the token into the text area. Decoding happens as you type, inside your own browser.

  3. 03

    Read header, payload and signature

    The header shows the algorithm and type, the payload holds the claims, and the signature is shown raw because it cannot be read without the key.

  4. 04

    Check the warnings

    Review the iat, nbf and exp dates and any warnings about expiry or alg: none before you treat the token as valid.

What a JWT is, and what you actually see when you decode one

A JSON Web Token in compact form is three blocks separated by dots: header.payload.signature. The first two are JSON encoded in Base64URL — encoded, not encrypted. Anyone holding the token can read them. Decoding breaks nothing; it simply undoes a transport encoding.

Which leads to the single most important rule: never put sensitive data in a JWT payload. Passwords, card numbers and personal data you would not show the client have no place there. The signature protects integrity, not confidentiality.

Decoding is not verifying

This tool decodes; it does not verify. Reading the payload tells you what the token *claims*, not whether that claim can be trusted. Verification means recomputing the signature with the correct key — an HMAC secret or an RSA/ECDSA public key — and confirming it matches, and that belongs on your server.

A token with perfect claims and an invalid signature is still a forged token. When you are debugging a 401, decoding tells you what is inside; verifying on the server tells you why it was rejected.

The claims that almost always matter

iss (issuer) and aud (audience) answer "who minted this" and "who is it for". A perfectly valid token issued for another service should not work on yours — validating aud is what prevents that hop.

iat, nbf and exp are NumericDate values: seconds since 1 January 1970 UTC, not milliseconds. This is the most common mix-up in the spec, and it produces tokens that expired in 1970 or expire in 55,000 years. Here they are shown as local dates.

sub identifies the subject and jti gives the token a unique ID, which is what revocation lists key on.

Why alg: none is flagged in red

alg: none means "this token carries no signature". The specification allows it for cases where integrity is already guaranteed by another layer, but for years it was the basis of a classic attack: take a legitimate token, change the header to none, empty the signature, and hand it to a library that trusted the header to decide how to validate.

The defence is to never let the token choose its own algorithm. Pin the expected algorithm on your backend and reject anything else. If you see alg: none in production, treat it as an incident until proven otherwise.

What this tool does not do

It decodes compact JWS with three segments. It does not verify signatures, does not generate or sign tokens, and does not decrypt JWE: paste a five-segment token and it will tell you the payload is encrypted and needs the private key.

It also stores nothing. The token is not sent over the network, not written to localStorage and not placed in the URL, so reloading the page clears it. Even so, a live production token is a credential — if you have pasted one anywhere, the healthy move is to rotate it.

Frequently asked questions

Is the token sent to a server?

No. Decoding happens entirely in your browser with JavaScript. The token is never transmitted, never stored in localStorage or cookies, and never added to the URL, so it does not end up in your history or in any proxy log.

Does this tool verify the JWT signature?

No, deliberately. Verifying a signature requires the secret key (HMAC) or the issuer public key (RSA/ECDSA), and that check belongs on your backend. Decoding shows you what the token claims; only server-side verification tells you whether to believe it.

Is it safe to paste a production token here?

The token never leaves your browser, but an unexpired production JWT is a live credential. Best practice is to debug with test tokens and, if you have handled a real one, rotate it or wait for it to expire.

Why can I read the payload without any key?

Because a signed JWT (JWS) is not encrypted — the header and payload are simply JSON in Base64URL. The signature guarantees nobody modified the content, not that nobody can read it. If you need confidentiality, the format is JWE, which does encrypt the payload.

What does it mean when a token is expired?

It means the exp claim points to a moment that has already passed. exp is expressed in seconds since the Unix epoch in UTC, and is converted to your local time here. A correctly configured server will reject that token; you usually just need a new one via the refresh token or by signing in again.

What should I do if I see alg: none?

Be suspicious. alg: none indicates an unsigned token, and it has been the basis of impersonation attacks whenever a validation library trusted the algorithm declared in the header. Configure your backend to require a specific algorithm and reject the rest.

I pasted a token and it says this is a JWE. What is that?

A JWE (JSON Web Encryption) has five segments instead of three and carries encrypted content, not merely encoded content. It cannot be read without the corresponding decryption key, and this tool neither asks for nor processes one.

Can I edit the claims and re-sign the token?

No. This tool is read-only by design. Editing and re-signing requires the secret key, and asking you to paste a private key into a web page is exactly what this tool exists to avoid.

Developers

.env Validator

Catch quoting, duplicate and syntax bugs in a .env file before they break your deploy.

Developers

Cron Expression Parser

Translate a cron expression into plain English and see exactly when it runs next.

Developers

UUID Generator

Generate cryptographically random UUID v4 or time-ordered UUID v7, in bulk.