All Tools

JWT Decoder

Paste a JSON Web Token to read its header and claims, see whether it's expired, and optionally verify the signature with a secret or public key — all without the token leaving your browser.

Runs in your browser — nothing is uploaded Free, no limits

Encoded token

Private by design: your token is decoded and verified entirely in this browser tab — nothing is sent to any server. Even so, treat production tokens like passwords: anyone holding a valid token can use it, so never paste live tokens into sites that upload them.

How to use the JWT Decoder

  1. Paste your JWT — a “Bearer ” prefix is removed automatically.
  2. Read the decoded header and payload, and the claims table with human-readable times.
  3. Check the status line: expired, not yet valid, or valid for how much longer.
  4. To verify the signature, enter the HMAC secret or paste the public key (PEM, certificate or JWK).

Frequently asked questions

Is it safe to decode a JWT online?

Decoding itself is harmless — a JWT's header and payload are only Base64url-encoded, not encrypted. The risk is sites that send your token to their server, where a still-valid token could be reused. This tool decodes and verifies everything locally in your browser.

Can a JWT be decoded without the secret?

Yes. Anyone can read a signed JWT (JWS); the secret or key is only needed to verify the signature or create new tokens. That's why you should never put passwords or other secrets in a JWT payload. Encrypted JWTs (JWE, 5 parts) can't be read without the key.

What do exp, iat and nbf mean?

They are times in seconds since 1 January 1970 (UTC). exp is when the token expires, iat is when it was issued, and nbf (“not before”) is when it becomes valid. Servers usually allow a small clock skew of a minute or so.

What's the difference between HS256 and RS256?

HS256 uses one shared secret for both signing and verifying, so every verifier could also forge tokens. RS256 (and ES256, PS256, EdDSA) sign with a private key and verify with a public key, so services can verify tokens without being able to create them.

Why is “alg: none” dangerous?

A token with alg “none” has no signature, so anyone can write any claims into it. Libraries must reject such tokens unless explicitly configured otherwise; accepting them has caused real authentication bypasses.

Where do I find the public key to verify a token?

Most identity providers publish their keys as a JWK Set at a URL like https://your-issuer/.well-known/jwks.json (linked from /.well-known/openid-configuration). Paste that JSON here — the key matching the token's kid is picked automatically.