JWT decoder

Decode, verify and build JSON Web Tokens. Nothing leaves your browser.

Mode

JSON Web Token

Decoded header

Decoded header view
Decoded payload
Decoded payload view
Secret to verify the signature (HS256, HS384, HS512)
How to decode and verify a JWT
  1. Paste the token
    Paste a JWT into the Decoder, with or without a Bearer prefix. The three parts are coloured: red header, violet payload, blue signature. Press Sample or Generate example if you just want to see one.
  2. Read the claims
    The header and payload appear as JSON. Switch to Claims for a plain note on each field, with exp, nbf and iat shown as dates. The lines under the token say whether it is valid, expired or not yet usable.
  3. Verify or build
    Enter the shared secret to check an HS256, HS384 or HS512 signature. To make a token, switch to Encoder, edit the header and payload JSON, type a secret and copy the signed token.
Good to know
  • Decoding needs no secret. The header and payload are only base64url encoded, so anyone holding a token can read them. Never put passwords or private data in a JWT.
  • Valid JWT means the structure decodes and says nothing about who signed it. Only Signature verified, after you enter the secret, proves the token has not been altered.
  • Tick Base64url encoded if your secret is stored as base64, as some identity providers do. Otherwise the raw text of the secret is used as the key.
  • Time claims are seconds since the Unix epoch. Hover over one in the JSON view for the readable date. Expiry is compared with your computer's clock.
  • Switching from Decoder to Encoder carries the decoded header and payload across, so you can change a claim and re-sign it with your own secret for testing.
  • Ctrl+C (Cmd+C on Mac) with nothing selected copies the decoded payload, or the signed token in Encoder mode. Signing and verifying use the Web Crypto API in your browser.
Questions people ask
Is my token safe to paste here?
Yes. Decoding and signing happen in your browser with no network request. Even so, treat production tokens as secrets and prefer test tokens.
Why can't RS256 or ES256 tokens be verified?
Those need the issuer's public key. This tool verifies shared-secret (HMAC) signatures only.
What does Invalid signature mean?
The signature does not match the header and payload under the secret you entered. Either the secret is wrong, it is stored as base64 and the Base64url encoded box is not ticked, or the token was changed after it was signed.
Why is my token marked as expired?
Its exp claim is earlier than the current time on your computer. Expiry is compared with your clock, so a wrong system time can show a live token as expired or the other way round.
Can I use a token made here with a real API?
Only if that API accepts HS256, HS384 or HS512 and you know its secret, which is the case for many test and local setups. Tokens for RS256 and other public-key algorithms need the issuer's private key, which this tool cannot use.