Paste a token to read its header, payload and expiry
Runs in your browser. Nothing you type is sent anywhere. Updated on 24 Oct 2026.Paste a token and its three parts are pulled apart: the header with the signing algorithm, the payload with its claims, and the signature left as it stands. Expiry, issued-at and not-before are shown as readable dates with the time remaining, which usually settles the question that brought you here. Decoding proves nothing about who issued it; a signature can only be checked against the key, on the Verify tab.
The page opens on the "Decode & verify" tab; paste the token into the Encoded token box.
Read the Header pane for the signing algorithm and the Payload pane for the claims.
Check Claims explained for the expiry, issued-at and not-before times, with the time remaining.
Use the copy icon beside Header or Payload to copy that part as formatted JSON.
This JWT decoder reads any JSON Web Token and shows its header, payload and signature as three colour-matched parts. Every standard claim gets a plain-English line, the expiry is turned into a real date and a "valid" or "expired" badge, and you can verify the signature with HS256, HS384, HS512, RS256 or ES256.
People reach for it when a login suddenly fails and they need to know whether the token expired or was issued for a different audience. It is also the fastest way to see what a third-party API actually puts inside its access tokens before you write code that depends on a claim. The encode tab covers the other direction: when you are building an auth flow and need a token with a specific subject, scope and expiry to test against your own service, you can edit the JSON, pick an algorithm, set the expiry and sign it with a secret or a generated test key pair.
Everything runs in your browser with the WebCrypto API. Tokens, secrets and keys are never sent anywhere and are not stored, so it is safe to paste real tokens. Signing here is for testing systems you own; production tokens should come from your auth server with a key only it holds.
The rest of the article, and all 6 questions about JWT Decoder, Verifier & Encoder, are on the JWT Decoder, Verifier & Encoder page.
Yes. Decoding and verification run in your browser with JavaScript and the WebCrypto API. The token, the secret and any key you enter never leave the page and are not saved, so a production token stays private. Still, treat any token you paste anywhere as something you should rotate if it is long-lived.
A JWT is signed, not encrypted. The header and payload are plain JSON encoded with Base64URL, so anyone holding the token can read them. The secret or key is only needed to check the signature, which proves the token was issued by whoever holds that key and was not altered.
Paste the token, choose the algorithm from the header (usually HS256 or RS256), enter the shared secret for HS algorithms or the PEM or JWK public key for RS256 and ES256, then press Verify or Ctrl+Enter. A green badge means the signature matches; a red one means the key is wrong or the token was changed.
Yes. Open the Encode & sign tab, edit the header and payload JSON, pick HS256, HS384, HS512, RS256 or ES256, choose an expiry preset such as 1 hour or 30 days, and sign with a secret or private key. Generate test key pair produces a PEM key pair in the browser for RS256 or ES256.
Still stuck? Ask about JWT Decoder, Verifier & Encoder and anybody who knows can answer. No account needed.
On the related tools: Set-Cookie Header Generator – Build a Set-Cookie line with Secure, HttpOnly, SameSite and __Host-, checked as you go · Remove Tracking Parameters – Strip utm, fbclid and gclid from a link before you share it · Passphrase Generator – Three to ten random words you can actually remember.
In the collection Security Tools for Developers.