JWT Decoder

Paste a JSON Web Token to read its header and payload, see when it was issued and when it expires, and check the standard claims — decoded entirely in your browser; the token never leaves your machine.

How this tool works

A JWT is three base64url-encoded segments joined by dots. The tool splits them, decodes the first two as UTF-8 JSON (tolerating missing padding and the standard Base64 alphabet, since tokens copied from logs are often mangled), and keeps the third as the raw signature. It then reads the registered claims — the algorithm and key ID from the header; issuer, subject, audience and the exp / iat / nbf timestamps from the payload — and works out whether the token is expired, not yet valid, or still within its window.

It does not verify the signature, and it says so on every result. Verification needs the issuer's secret or public key, which belongs on your server, not in a browser tab. Everything here runs locally — the token is never uploaded.

Frequently asked questions

Is it safe to paste a real token here?

The decoding happens entirely in your browser — the token is never sent to CheckSEO or anyone else, and you can confirm that in the Network tab of your dev tools. That said, a live access token is a credential: anyone who has it can act as you until it expires. Prefer decoding tokens from a development environment, and if you paste a production one, treat it as you would a password you've just typed somewhere unfamiliar.

Why doesn't this tool verify the signature?

Because verification needs a secret this tool doesn't have. An HS256 token is signed with a shared secret, and RS256, ES256 and EdDSA tokens are signed with a private key whose matching public key belongs to the issuer. Without that key, all anyone can do is read the header and payload — which are just Base64, not encrypted. A tool that asked you to paste your signing secret into a web page would be teaching a very bad habit, so verify on the server with a library such as jose or jsonwebtoken instead.

What do exp, iat and nbf mean?

They're the three time claims from RFC 7519, each a NumericDate — whole seconds since 1970-01-01 UTC, not milliseconds. iat (issued at) is when the token was created, nbf (not before) is the earliest moment it may be accepted, and exp (expiration) is the moment after which it must be rejected. This tool converts each to an ISO date and a relative time, and warns when a value looks like milliseconds, which is a common bug that makes tokens appear to never expire.

The token shows as expired, but my app still accepts it. Why?

The most common reasons are that the server allows a few minutes of clock skew (leeway), that the app silently used a refresh token to get a new access token, or that the server never checks exp at all — which is a real vulnerability worth fixing. Compare the exp shown here with your server's clock, and confirm your verification library has expiry checking switched on.

What's the difference between a JWT, a JWS and a JWE?

JWT is the umbrella term for a token whose claims are JSON. A JWS is a signed JWT — three dot-separated segments (header.payload.signature) with a readable payload, which is what almost everyone means by "JWT" and what this tool decodes. A JWE is an encrypted JWT with five segments; its payload can't be read without the decryption key, so this tool recognises the shape and tells you rather than showing garbage.

Related tools

JSON FormatterUTM Link BuilderBase64 Encoder / DecoderURL Slug Generator

Command Palette

Search for a command to run...