JWT Decoder

Decode JWT tokens and inspect header, payload, claims, and expiry instantly.

JWT TOKEN

When a JWT decoder is the right tool

A JSON Web Token is three Base64url segments joined by dots: a header, a payload, and a signature. The middle part often holds an expiry, a subject, and other claims, but the raw string is hard to read. A decoder is for that moment. You paste the token and see the header and payload as JSON, plus the signature segment and, when exp is present, whether that timestamp is still in the future.

This page does not verify the signature. It cannot tell you whether a server would accept the token. The green Token is valid banner, when it appears, only means the numeric exp claim has not passed yet. If you need a dedicated look at remaining time, try the JWT Expiry Checker. If you need to mint a token rather than read one, use the JWT Generator.

Use cases

Reading the claims in a token you already have

During debugging you often need to know which sub or iss a token carries, or which algorithm the header names. Paste the token and read the JSON. You can copy the pretty-printed header or payload if you need to file a note. Load Sample pastes a well-known public example if you only want to see the layout.

Checking whether exp is in the past

If the payload includes a numeric exp (Unix seconds), the page shows either “Token is expired” or “Token is valid”, together with the expiry as an ISO timestamp. That is a clock check, not a cryptographic one. A missing or non-numeric exp means the banner is omitted. The nbf claim is not used.

Confirming the token is well-formed before you dig further

A token with a leftover “Bearer ” prefix, only two parts, or five JWE parts will not decode here. Getting a clean header and payload first saves time before you move to signature verification in your own environment, where the key actually lives.

How decoding works

The input is trimmed and split on .. There must be exactly three parts. Each of the first two is treated as Base64url: - and _ are converted to + and /, padding is added if needed, and the result is decoded and parsed as JSON. The third part is shown as the raw signature segment; it is not decoded into bytes and it is not verified. The output updates as you type.

When the token has three parts, a colorized preview shows the header, payload, and signature in purple, blue, and pink — the same colors used on the decoded cards. A claims summary appears for string sub and iss values and for numeric iat and exp, which are converted to dates. Other claims remain visible in the full payload JSON.

Example — three Base64url segments, not a verified credential
header.payload.signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiZXhwIjo5OTk5OTk5OTk5fQ
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

A compact JWT is always of this shape. The first segment decodes to a header (algorithm and type), the second to a payload (claims), and the third is the signature input as it was sent. Seeing those parts is useful; it is not the same as checking that the signature matches a key.

What this tool does not do

It does not verify a signature, fetch a JWKS, check nbf, or accept encrypted JWE tokens. It does not strip a Bearer prefix for you. It does not send the token to a server. Treat any real token as sensitive: if you would not paste it into a random website, think twice before pasting it here, even though the work stays in this browser.

How to use JWT Decoder

  1. Paste a compact JWT (three dot-separated parts) into the input. The decoded view updates as you type.
  2. Read the banner, if any: it reflects only the exp claim. Then read the header, payload, and the signature note under the third card.
  3. Copy the header, payload, or signature segment if you need a record.
  4. Use Load Sample to inspect a public example, or Clear when you are finished.

For another decoded view of the same kind of token, see the JWT Inspector. To work with ordinary Base64 rather than JWT segments, use Base64 Encode / Decode.

Frequently asked questions

Does this page verify the signature?

No. It decodes the header and payload and displays the signature segment as it appeared in the token. It does not use a secret or a public key, and it does not talk to a JWKS endpoint. A green “Token is valid” banner only means the exp claim is still in the future. Anyone can create a token with a future exp, so that banner is not a security check.

What does “Token is valid” actually mean?

If the payload has a numeric exp claim, the page compares it with the current time. When exp is in the future, the banner says “Token is valid”; when it is in the past, it says “Token is expired”. If there is no numeric exp, the banner is hidden. nbf (not-before) is not checked. The signature is never checked.

What counts as a valid JWT on this page?

The input must have exactly three dot-separated parts after trimming whitespace. The first two parts are treated as base64url, padded if needed, decoded, and parsed as JSON. Encrypted JWE tokens (five parts), a Bearer prefix left on the token, or a malformed segment will show “Invalid JWT — token must have 3 dot-separated parts” or fail to decode.

Which claims are highlighted?

A short summary appears when the payload has a string sub or iss, or a numeric iat or exp. Those four are shown as cards. Other claims still appear in the full JSON payload. iat and exp are converted from Unix seconds to a date; a claim stored as a string is not treated as a timestamp.

Is the token sent to a server?

No. Decoding runs in your browser as you type. Closing the tab discards what you pasted. A JWT is often as sensitive as a password. Do not paste a production token if you would not be comfortable with it sitting in memory on this device.

Can I decode the sample safely?

Yes. Load Sample pastes a well-known public example (the same shape of token often used in JWT documentation), not a live credential. It is useful for seeing the header, payload, and signature layout without using a real token.

How is this different from the JWT expiry checker or inspector?

This page is the general decoder: header, payload, signature, and a simple exp check. The expiry checker is aimed at time remaining and standard time claims. The inspector is another view of the same kind of decoded token. None of these pages verify the signature.

Related tools and guides

References

  • RFC 7519 defines JSON Web Tokens, including the header, payload, and signature segments, and registered claims such as exp, iat, iss, and sub.
  • RFC 7515 (JWS) describes how the signature is computed. Verifying it requires the correct secret or public key; displaying the segment is not the same as verifying it.
  • Treat a JWT like a credential. Decoding one in a browser tab is convenient for debugging, but it is not a substitute for server-side verification in an application.