JWT

JWT Decoder

Details

How to use JWT Decoder

What the tool does, how to run it, and what to expect from the result.

How to decode a JSON Web Token

A JWT is three base64url segments separated by dots: a header naming the algorithm, a payload holding the claims, and a signature. Decoding the first two is how you debug an auth problem: you find out who the token says the user is, when it expires, and which issuer minted it.

The important thing to hold on to is what decoding proves, which is nothing. The decode succeeds regardless of whether the signature is real. It runs entirely in your browser, so the token is never transmitted, but the result is an inspection aid and never an authentication decision.

  • Paste the full token, including all three dot-separated segments, into the input box.
  • Read the decoded header to see the alg (algorithm) and typ fields. If alg is none, the token is unsigned.
  • Read the decoded payload to check the claims: sub (subject), exp (expiry), iat (issued at), iss (issuer), and aud (audience).
  • Convert exp and iat from Unix seconds to a date if you need to reason about timing, remembering that they are seconds and not milliseconds.
  • Verify the signature on your server with the real key before trusting anything you have read.
Tips

Getting a better result out of JWT Decoder

Specific settings and thresholds, not general advice.

  • A JWT is signed, not encrypted. Anyone holding the token can read its payload, so never put a password, a card number, or any secret inside a JWT. The signature proves the token was not modified. It does nothing to hide the contents.
  • This tool decodes. It does not verify. It splits the token, decodes the header and payload, and pretty-prints them. It never checks the signature, which means a token with a forged or garbage signature will decode here and look perfectly normal. Never treat a decode as proof that a token is valid.
  • Signature verification belongs on the server, with the secret or public key, and it must happen on every request. If your backend decodes a JWT without verifying it, an attacker can change the payload (say, role from user to admin) and you will accept it.
  • Check the alg field in the header first. If it says none, the token is unsigned and should be rejected outright. If your library accepts alg: none or lets the token choose between HS256 and RS256, that is the classic JWT key-confusion vulnerability.
  • The exp, iat, and nbf claims are Unix timestamps in seconds, not milliseconds. A common bug is comparing them against JavaScript's Date.now(), which returns milliseconds, making every token look valid for another 50,000 years.
Limits

What JWT Decoder does not do

The honest boundary, so you do not lose time finding it yourself.

  • It does not verify the signature. It never asks for a secret or a public key, and it will happily decode a token whose third segment is nonsense.
  • It does not check expiry. The exp claim is shown as a raw Unix timestamp, and no comparison against the current time is made, so an expired token looks the same as a fresh one.
  • It does not decrypt JWEs. Encrypted tokens (five segments rather than three) cannot be read without the key, and this tool cannot read them.
  • It shows only the header and payload. The signature segment is not displayed or analysed.
Reference

Terms used on this page

Short, plain-language definitions for the formats and settings above.

At a glance

Who JWT Decoder is for

A quick way to understand who this helps, what it solves, and where it connects next.

Best fit

Developers, engineers, and anyone working with encoded data.

Ideal for

Quick encoding, decoding, and inspection without a backend or install.

FAQ

Common questions

Short answers for the questions people usually have before trying a utility like this.

Is the JWT decoder free?

Yes. It is completely free to use, with no signup, no account, and no paywall.

Do I need to install anything?

No. It runs in any modern browser on desktop or mobile, with nothing to download and nothing to configure.

Does it stay local?

Yes. The token is decoded entirely in your browser and never sent anywhere, which matters because JWTs often carry account and session details.

Does this tool verify the token, and does that matter?

It does not verify, and yes, it matters enormously. Decoding only reverses the base64url encoding of the header and payload, which requires no key at all. Verification is a cryptographic check of the signature against a secret (HS256) or a public key (RS256), and only that check proves the token is authentic and unmodified. This decoder is an inspection tool for debugging, not an authentication step, and no security decision should ever rest on it.

Is it safe to paste a production token into this page?

The decoding runs entirely in your browser: the token is split and decoded with local JavaScript and is never sent to a server, never logged, and never stored. That is a genuine security property and the reason this tool exists rather than sending you to a service that posts your token over the network. Even so, treat any live token you paste anywhere as something you would rather rotate afterwards, because a valid JWT is a bearer credential: whoever holds it is the user.

Why can I read the payload without any key?

Because the payload is only base64url-encoded JSON, and base64url is an encoding, not a cipher. The JWT design assumes claims are readable by anyone in the chain, including the browser. The signature exists so that a recipient can detect tampering, not to keep the contents private. If you need the claims to be confidential, you need JWE (an encrypted token) or you keep the sensitive data server-side and put only an opaque reference in the token.

My token decodes fine but the API rejects it. Why?

A successful decode tells you nothing about validity. The most likely causes are that the token has expired (check exp against the current Unix time in seconds), the signature does not match the key the server holds, the iss or aud claims do not match what the server expects, or the token was issued by a different environment. Decoding gives you the claims to inspect; the rejection reason will be in one of them or in the signature.

What is the third segment of a JWT?

It is the signature: the result of running the algorithm named in the header over the first two segments, joined with a dot. For HS256 it is an HMAC computed with a shared secret. For RS256 it is an RSA signature made with a private key and checkable with the public key. This tool does not display or evaluate it, so you should assume nothing about it from a successful decode.

Can I edit the payload and re-sign the token here?

No. This tool is read-only. Creating a valid token requires the signing key, and if you have that key you should be minting tokens from your own backend or auth provider rather than from a web page. Any tool that offers to sign a JWT for you in the browser is asking you to paste a signing secret, which is a habit worth avoiding.

Recommendations

You Might Also Like

Nearby tools from the catalog that fit the same job or workflow.

Cleanor app

Do it all on your device

Cleanor puts these tools in one app: compress and convert images, video, and audio, work with PDFs, and scan text right on your device. Plus free up storage and clear inbox clutter with Email Cleaner. Start with a free trial.

  • iPhone
  • Android
  • Macsoon
  • Windowssoon