Loading tool…
ToolWrenPaste a JSON Web Token to instantly read its header and payload as formatted JSON, and see whether it has expired. Decoding happens entirely in your browser.
Loading tool…
JWT is a free, private online tool that lets you decode a JSON Web Token to inspect its header and payload, with an automatic expiry check. It runs entirely in your browser, so nothing you enter is uploaded to a server.
Bearer prefix is removed automatically.Privacy: this tool runs entirely in your browser. Your input is never sent to, received by, or stored on any server — there are no uploads and no tracking of what you enter.
A JSON Web Token (JWT) is a compact, URL-safe token format used for authentication and information exchange. It has three Base64URL-encoded parts separated by dots: header.payload.signature.
The header describes the signing algorithm (e.g. HS256, RS256). The payload contains claims such as sub, iat and exp. The signature is computed over the header and payload with a secret or private key to prove integrity.
This tool decodes and displays the token contents, including a friendly expiry check based on the exp claim. It does not verify the signature, which requires the secret/public key. Never trust a token's claims without verifying its signature server-side.
exp claim is a Unix timestamp. If that moment is in the past, the token is expired and most servers will reject it.iat = issued-at time, nbf = not-valid-before time, exp = expiry time. All are Unix timestamps in seconds.A JSON Web Token (JWT, pronounced 'jot') is an open standard (RFC 7519) for representing claims securely between two parties. In practice it is most often used for stateless authentication: after you log in, a server issues a signed token that your browser or app sends with each subsequent request. Because the token is self-contained and signed, the server can trust it without looking anything up in a database, which makes JWTs popular for APIs, single sign-on (SSO) and microservices.
A JWT is three Base64URL-encoded sections joined by dots: header.payload.signature. The header is a small JSON object naming the signing algorithm (e.g. HS256 or RS256) and token type. The payload is JSON containing the claims — data such as the user id (sub), issuer (iss), audience (aud), and timestamps. The signature is produced by signing the encoded header and payload with a secret or private key, and it is what makes the token tamper-evident.
The spec defines standard 'registered' claims that carry special meaning: iss (who issued it), sub (the subject/user), aud (intended audience), exp (expiry time), nbf (not valid before), iat (issued-at time) and jti (a unique token id). The time-based claims are Unix timestamps in seconds. This decoder converts exp, nbf and iat into human-readable dates and shows at a glance whether a token has expired — the single most common cause of '401 Unauthorized' errors during development.
Anyone can decode a JWT, because the header and payload are merely Base64URL-encoded, not encrypted. Decoding reveals the claims but proves nothing about authenticity. Verifying is different: it recomputes the signature using the signing key and checks it matches. Only verification proves the token was issued by a trusted party and has not been altered. This tool decodes instantly in your browser, and can also verify HS256/384/512 (with the shared secret) and RS/ES/PS signatures (with a public key) using the Web Crypto API — but the keys never leave your device.
For the common HS256 algorithm, the signature is HMAC-SHA256(base64url(header) + '.' + base64url(payload), secret). Change a single character in the header or payload and the recomputed HMAC no longer matches, so tampering is detected. Asymmetric algorithms like RS256 sign with a private key and verify with the corresponding public key, which lets many services verify tokens that only one service can issue. Never accept the alg: none 'unsigned' option in production — it has caused real authentication-bypass vulnerabilities.
Treat JWTs as bearer credentials: anyone holding a valid token can use it, so always transmit them over HTTPS and store them carefully (HttpOnly cookies are safer than localStorage against XSS). Keep payloads small and never put secrets in them, since the contents are readable by anyone. Use short expiry times with refresh tokens to limit damage if a token leaks. And always verify the signature server-side with a whitelisted algorithm — client-side decoding (like this tool) is for inspection and debugging, never for making authorization decisions.