See inside any JWT — header, payload and expiry

Paste the encoded JWT (the long eyJ… string) into the input box. The tool splits it on the two dots, Base64URL-decodes the header and payload, and shows the JSON for each plus the raw signature segment — all without making any network request.

No. The decoder only parses the token — it does not check the signature against a secret or public key, because verification requires the issuer's key material. Use a server-side JWT library for production verification; this tool is for inspection and debugging.

You get the header (algorithm and key id), the payload claims (sub, iss, aud, iat, exp and any custom claims) and the raw signature. Standard timestamp claims are formatted as human-readable dates so you can spot stale tokens at a glance.

If the payload contains the standard "exp" claim, the tool compares it to the current time and shows either "Valid until" or "Token expired at" with the exact timestamp. Tokens without an exp claim are reported as having no expiry.

Anyone who reads the payload of a JWT can use it until it expires, so production tokens belong in private tools. This decoder runs entirely in your browser and never transmits the token, but the safer rule is to decode short-lived development tokens whenever possible.

A JWT has three Base64URL-encoded segments separated by dots: header (signing algorithm), payload (the claims the issuer wants the verifier to trust) and signature (a MAC or digital signature over header.payload). Decoding never needs a key — only verification does.

A compact, URL-safe token made of three Base64URL segments — header, payload and signature — that carries signed claims such as a user ID and an expiry time. It is widely used for stateless login sessions and securing API requests. Paste one above to inspect its header and payload.

Below the decoded header and payload, paste the signing secret (for HS256) or the issuer's public key in PEM or JWK format (for RS256, ES256 and similar) into the Verify signature box, then click Verify. The badge that appears reports whether the signature is valid, invalid, or uses an algorithm the browser-side verifier doesn't support — all computed locally, without sending the token or key anywhere.

For HMAC algorithms like HS256 you paste the raw shared secret string. For asymmetric algorithms like RS256, RS384 or ES256 you need the issuer's public key — never the private key — supplied as a PEM block or a JWK; pasting the wrong half of an asymmetric key pair will make verification fail even though the token is valid.

The Verify signature panel supports every mainstream JOSE algorithm: HS256/384/512 (HMAC with a shared secret), RS256/384/512 (RSASSA-PKCS1-v1_5 with an RSA public key), PS256/384/512 (RSA-PSS with an RSA public key) and ES256/384/512 (ECDSA over the matching P-256/P-384/P-521 curve). Tokens signed with "none" or any algorithm outside this list are always reported as unsupported rather than marked valid, which also protects you from the classic alg=none forgery trick.

The most common cause is pasting extra whitespace or a trailing newline into the secret box — the verifier hashes the exact bytes you enter, so a copy-paste artifact breaks the match. Also double-check you're verifying the current token: if the JWT was re-issued after you copied it, or the provider's secret is base64-encoded rather than a raw string, decode it first before pasting it in.

Click Try sample JWT to load a demo HS256 token with sub, name, iat and exp claims so you can see decoding and expiry checking work before pasting your own token. Once a token is in the box, a Clear button appears next to it that wipes the input back to empty in one click.

Each of the Header, Payload and Signature panels has its own Copy button in its top-right corner that copies only that section's JSON (or the raw signature string) to your clipboard. There's also a primary Copy Payload button below the panels for the most common case of grabbing just the claims to paste into a debugger or bug report.

Copy the value after 'Bearer ' in the Authorization header — the eyJ… part is the JWT itself — and paste it into the decoder to see the header, payload claims and expiry status instantly. If you grab the whole 'Bearer eyJ…' string, remove the 'Bearer ' prefix first so the token has exactly three dot-separated parts.

No — this is a decoder and viewer, not a JWT editor. Changing the payload would invalidate the signature, so any server verifying the token would reject the tampered version. To change claims you must issue a new token signed with the correct secret or private key. Use the decoder to read and debug tokens, not to modify them.