Skip to content
Utilboxes

JWT Decoder

Paste a JSON Web Token to read its header and payload as formatted JSON, with the exp, iat and nbf times shown as real dates and a clear expired or valid label. A “Bearer” prefix is stripped. Decoding is not verification: it cannot prove who issued the token. The token never leaves your browser.

Runs entirely in your browser

Updated

How to use the JWT Decoder

  1. 1Paste the token, with or without the “Bearer ” prefix.
  2. 2Read the header and payload, shown as formatted JSON.
  3. 3Check the claims table for issue and expiry times in your time zone.
  4. 4Copy the parts you need, then verify the token on your server.

How it works

A JWT is three Base64URL-encoded parts joined by dots: a header, a payload and a signature. The header and payload are JSON, so decoding them is just reversing the Base64URL encoding — no key is needed, which is why anyone holding a token can read it.

The registered claims from RFC 7519 are explained: iss (issuer), sub (subject), aud (audience), jti (token ID), and the three times — iat (issued at), nbf (not before) and exp (expiry). Times are Unix timestamps in seconds and are converted to dates in your time zone, with how long ago or how soon they are.

Expiry is judged against this device's clock. A wrong clock, or a server that allows a minute or two of leeway, can change the answer at the boundary.

The signature is shown but not checked. Verifying it needs the issuer's secret (for HS256) or public key (for RS256 and ES256), and should happen on your server with a maintained JWT library. A token with alg set to none has no signature and should always be rejected.

A token with five parts is an encrypted JWE rather than a signed JWT; its contents can only be read with the recipient's private key, so it is reported rather than decoded.

Everything runs in this page. Nothing you paste is transmitted, logged or stored, which is what makes it safe to drop a production payload in here while you are debugging.

Tips and common mistakes

  • Check exp and iat first when debugging a 401 error — an expired token is the most common cause.
  • Compare aud and iss with what your API expects; a token for another audience will be rejected even if it is valid.
  • Times in JWTs are seconds since 1970, not milliseconds.
  • Treat any token you paste as a secret and let it expire or revoke it if it may have been exposed.

Frequently asked questions

Is it safe to paste a real token here?
The token is decoded in your browser and not sent anywhere. Even so, a live token is a credential: anyone who has it can use it until it expires, so avoid pasting production tokens into tools you have not checked.
Does decoding verify the signature?
No. Decoding only reads the header and payload. Checking the signature needs the issuer's secret or public key, and should be done by your server.
Why does my token show as expired?
The exp claim is earlier than this device's clock. Access tokens are often valid for only minutes; request a new one, or check your device's date and time.
Can JWT contents be secret?
Not in a normal signed JWT: the payload is only encoded, not encrypted. Never put passwords or other secrets in a JWT payload.
What does “Bearer” mean?
It is the authorisation scheme in the HTTP header: Authorization: Bearer <token>. The tool strips the word so you can paste the header value as it is.
What is the difference between HS256 and RS256?
HS256 signs with a shared secret, so the same secret signs and verifies. RS256 signs with a private key and verifies with the matching public key, so verifiers never hold the signing secret.
Share this toolShare on XShare on FacebookShare on LinkedInShare on RedditShare by email

Related tools

Base64 DecoderDecode Base64 back to text or download it as a file.Timestamp ConverterUnix time to a readable date, in UTC and your local zone.JSON FormatterPretty-print or minify JSON, with the exact error position.Hash GeneratorMD5, SHA-1, SHA-256 and SHA-512 hashes and HMACs of any text.