To decode a JWT, paste the token into the JWT token box on the Decode tab; it decodes as you type, or select Decode. The header and payload appear as formatted JSON, with exp, iat and nbf shown as readable UTC dates and a countdown to expiry. Decoding doesn't check the signature; use the Verify tab with the secret or public key for that.
How to decode a JWT
- Paste the token. On the Decode tab, paste it into the JWT token box or use Load token from file for a .txt, .jwt or .token file. Sample JWT gives you one to try.
- Decode it. It decodes as you type, or select Decode or press Ctrl+Enter. The summary shows the algorithm, type, subject, issuer and expiry, and Validation Notes flag problems.
- Verify the signature. Open the Verify tab, paste the token, keep the algorithm on the token's alg header or pick one, enter the secret or the public key (PEM or JWK), and select Verify signature.
- Copy what you need. Use Copy header, Copy payload or Copy report, or Download JSON for the full parsed report.
How a JWT decoder reads a token
A JSON Web Token (RFC 7519) has three parts separated by dots: header.payload.signature. The header and payload are JSON encoded with base64url, a URL-safe form of Base64 that uses - and _ and drops the = padding. The signature is binary, also base64url encoded.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 header {"alg":"HS256","typ":"JWT"}
.eyJzdWIiOiIxMjM0NTY3ODkwIi... payload {"sub":"1234567890", ...}
.SflKxwRJSMeKKF2QT4fwpMeJf36P... signatureBase64url is an encoding, not encryption, so anyone holding a token can read its payload. Never put passwords or other secrets in JWT claims. This page decodes in your browser without sending the token anywhere; you can also decode the payload yourself in the browser console:
const part = token.split('.')[1].replace(/-/g, '+').replace(/_/g, '/');
const bytes = Uint8Array.from(atob(part), c => c.charCodeAt(0));
console.log(JSON.parse(new TextDecoder().decode(bytes)));The Base64 encoder and decoder also works for a single segment.
Decoding a JWT is not verifying it
Decoding only shows what the token claims. Anyone can create a token with "admin": true in the payload; only the signature proves which key signed it and that nothing changed afterwards. Your server must verify the signature on every request before trusting any claim.
The Verify tab uses your browser's Web Crypto API. For HS256, HS384 and HS512, enter the shared secret (tick the base64 box if your secret is stored encoded) and the tool recomputes the HMAC over header.payload and compares it with the signature. For RS, PS and ES algorithms, paste the issuer's public key as PEM (-----BEGIN PUBLIC KEY-----, an RSA public key or a certificate) or as a JWK or JWKS; with a JWKS the key whose kid matches the token header is used.
RFC 8725, the JWT Best Current Practices, adds rules for your own code: let your library accept only the algorithms you expect, reject alg: none unless the token is protected some other way, and check exp, nbf, iss and aud as well as the signature. The sample alg=none token on this page shows what an unsigned token looks like: its third segment is empty.
JWT claims explained
| Claim | Name | Meaning |
|---|---|---|
iss | Issuer | Who created and signed the token |
sub | Subject | Who the token is about, usually a user ID |
aud | Audience | Which service the token is meant for |
exp | Expiration time | Don't accept the token after this time |
nbf | Not before | Don't accept the token before this time |
iat | Issued at | When the token was created |
jti | JWT ID | A unique ID, useful for revoking one token |
The time claims are NumericDate values: seconds since 1 January 1970 UTC, not milliseconds. 1893456000 is 1 January 2030, 00:00 UTC. The decoder converts each one to a readable UTC date in Claim Insights and runs a live countdown on exp. The expired check and the countdown both use your device's clock, so a wrong clock gives a wrong answer. Use Claim search to filter long payloads by claim name or value.
Where your token goes, and how to stay safe
This JWT token decoder runs entirely in your browser. Decode, Verify, Compare and Generate use JavaScript and the Web Crypto API on the page, so tokens, secrets and keys stay on your device and no request is sent to ToolzyLab. Recent History is off by default; if you turn it on, it keeps only the algorithm, issuer, expiry and a short SHA-256 fingerprint of each token in your browser's local storage, never the token itself.
A valid access token still works like a password until it expires. Prefer test or expired tokens, and keep production signing secrets and private keys out of web pages in general. If a real token was exposed, revoke it or rotate the key. The Generate tab is meant for building test tokens for development; it always sets the header's alg to the algorithm you pick, and Create a test key pair makes a throwaway RSA or EC key in the browser. For signing secrets, the password generator can create a long random string.
Frequently asked questions
How do I decode a JWT token?
Paste it into the JWT token box on the Decode tab. The header and payload are base64url-decoded and shown as JSON, with timestamps converted to readable dates.
Does decoding a JWT verify it?
No. Decoding only reads the claims, which anyone can do. To prove a token is genuine, verify its signature with the shared secret (HS256, HS384, HS512) or the issuer's public key (RS, PS or ES algorithms).
Is this online JWT decoder safe for production tokens?
Decoding, verifying and signing all happen in your browser with the Web Crypto API, so tokens, secrets and keys are not sent to ToolzyLab. A live access token still works like a password until it expires, so prefer test or expired tokens, and keep production private keys out of any web page.
Can a JWT payload be encrypted?
Standard signed JWTs (JWS) are only encoded, so the payload is readable. Encrypted JWTs (JWE) have five parts instead of three; this decoder handles three-part signed tokens only and tells you when it sees a JWE.
Why does my token show as expired?
The exp claim is earlier than the current time. exp is in seconds since 1970 UTC, so a value written in milliseconds by mistake looks like a date far in the future instead.
What does alg none mean in a JWT?
It marks an unsigned token with an empty signature segment. Servers should reject it unless the token is protected another way, and this tool flags it as a danger in Validation Notes.