JWT Decoder — Decode a JSON Web Token Online

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.

Only if you give it the key. Decoding the header and payload needs no key, but the Verify signature field accepts an HMAC secret (HS256, HS384, HS512) or an RSA or EC public key as PEM or JWK, and reports whether the signature is valid; the check runs in your browser. Tokens signed with none or an unsupported algorithm are never reported as valid. 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. The exp claim gets an expiry banner so you can spot stale tokens at a glance; iat and nbf are shown as the raw numbers.

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.

No — JWT Decoder runs entirely in your browser, so what you paste never leaves the machine you are on. That matters if you are checking something that contains a token, a key or customer data. Closing the tab is enough to clear it.

The error points at the first position that could not be parsed, which is usually just after the real mistake rather than on it — a missing comma, an unclosed quote or bracket, or a smart quote pasted in from a document instead of a straight one. Check the line above the reported position first.

JWT Decoder shows its result on the page. Standard use does not require signup; this workflow does not offer a file download. Published processing allowances and file limits still apply.

No — JWT Decoder runs in the browser on desktop and phone. There is nothing to install, no trial to start, and no license to buy before you can see whether it does what you need. Try it on the file you are actually stuck with rather than a sample.

The banner compares the exp claim with your device clock, so a clock set ahead of real time marks a token expired too early. Check the date, time and time zone on your computer. Also make sure you pasted the newest token, because an older copy from a log or a cached request carries its original, earlier exp.

The Payload panel prints the claims exactly as stored. iat, nbf and exp are Unix timestamps counted in seconds since 1 January 1970, so they appear as numbers like 1700000000. Only exp is turned into a readable date, in the banner above the panels. A 13-digit value would be milliseconds, which the standard does not use. Multiply a seconds value by 1000 to use it with a JavaScript Date.

A signed JWT has exactly three segments joined by dots. Fewer usually means the token was cut off or you copied only a segment. Five segments is an encrypted token, which cannot be read without its key. Remove any spaces, line breaks and the Bearer prefix, then paste the whole value again.

The badge reads Unsupported algorithm followed by its name when the token header names one the verifier does not handle. A header that says none, or has no algorithm, gets a message that it cannot be verified. The panel covers HS, RS, PS and ES with 256, 384 and 512 bits, and a token marked none is never reported as valid.