JWT Decoder
⚡ Runs locally🔒 No uploads🆓 Free, no sign-up
A JSON Web Token (JWT) is a compact, URL-safe way to carry claims between two parties, and it always has the same shape: three segments separated by dots — header, payload, signature. The header declares the signing algorithm (such as HS256) and the token type; the payload is a set of claims like sub (subject), exp (expiry) and iat (issued-at); the signature is computed over the first two segments with a secret key to prevent tampering. Each segment is Base64Url-encoded — a URL-safe variant of Base64 that swaps +/ for -_ and strips trailing padding, so the token can travel inside URL parameters. Decoding merely reverses that encoding: anyone holding the token can read the payload. It is encoded, not encrypted.
Three everyday scenarios cover most uses. First, when wiring up a login API, paste the access_token the backend returns and instantly confirm that sub is the right user and how long until exp — no more console.log archaeology. Second, when a user reports being 'suddenly logged out', paste the token from their request headers and check exp to tell token expiry apart from a signature problem in seconds. Third, when integrating a third-party OAuth or SSO provider, verify that the iss (issuer) and aud (audience) claims in the id_token match your expectations before anything reaches production.
Watch out for four common pitfalls. exp is a seconds-based timestamp (10 digits); some systems mistakenly emit milliseconds (13 digits), which this tool reads as seconds and renders as a date tens of thousands of years out — check the digit count first. Tokens with alg set to none carry no signature and can be forged by anyone, so production systems must reject them. An expired token always earns a 401 from the server; guide the user to log in again instead of retrying the same request. Stray spaces or line breaks from copy-paste trigger the 'Illegal base64url string' error — trim the ends and try again.
One security reminder: the JWT payload is merely encoded, never put passwords or personal identifiers inside a token. Signature verification needs the secret key, and this tool performs it entirely in your browser via WebCrypto — your secret and token are never sent to any server (this page has no backend at all). Even so, only paste test tokens into any online tool; if a production token is ever exposed, the safest move is to revoke it and rotate immediately.
How to use
- Paste the full JWT (header.payload.signature) into the input, or click “Load example”
- The tool splits header, payload and signature automatically; exp/iat/nbf are shown as readable dates with validity status
- To verify the signature, enter your HS256 secret and click “Verify signature” (the example token's secret is demo-secret)
- Click “Copy payload” to export the formatted payload JSON
FAQ
What are the three parts of a JWT?
The header declares the signing algorithm (alg) and token type (typ); the payload is a set of claims such as sub (subject), exp (expiry) and iat (issued-at); the signature is computed over the first two segments with a secret key to prevent tampering. This tool splits the three segments and formats each one.
How do I read exp, iat and nbf?
They are Unix timestamps in seconds. This tool converts them to readable local dates and marks exp with a status: expired tokens show red, valid ones show the remaining days, hours or minutes, and an nbf in the future is flagged as not yet valid. Some systems emit millisecond timestamps (13 digits); if you see a date tens of thousands of years out, that is the cause.
What should I do about an expired token or an invalid signature?
An expired token means exp is in the past — that is the security mechanism working as intended. Log in again for a fresh token; do not try to extend exp, the signature will no longer match. An invalid signature has three likely causes: a wrong secret, a truncated or tampered token, or an algorithm mismatch (e.g. verifying an RS256 token with an HS256 secret). Check that the token has all three segments first, then the secret and algorithm.
Why do I get an 'Illegal base64url string' error?
Each JWT segment must use Base64Url characters (A–Z, a–z, 0–9, -, _). The usual causes are stray spaces or line breaks from copy-paste, a truncated token with only two segments, or plain Base64 (with +/) instead of the URL-safe variant. Trim whitespace and confirm the full three-segment shape before decoding.
Are my token and secret uploaded anywhere?
No. Decoding is pure string math and signature verification uses the browser's built-in WebCrypto — everything happens locally, and this page has no backend to send anything to. Still, prefer test tokens for online decoding; if a production token is ever pasted into a third-party page, revoke and reissue it right away.