Back

JWT Decoder & Validator

Decode a JSON Web Token's header and claims, check exp, nbf and iat, and verify the signature with your own key. Everything runs in this tab.

Structure

Waiting for a token

Paste a token to decode it.

Signature

Unverified

Nothing is verified until a signature check passes.

Time claims

-

exp, nbf and iat show up here.

The token and key stay in this tab. They aren't uploaded, saved, put in the address bar or included in share links. Clear them when you're done.

Try an example

Verify the signature

HS algorithms use a shared secret. RS, PS, ES and EdDSA use the issuer's public key.

Readable claims aren't proof. Anyone can write a token that says "role": "admin". Only a signature check with the right key shows who signed it.

Time settings

Show times in

Leeway lets exp and nbf pass when two clocks are a little apart, like the clockTolerance or leeway option in most JWT libraries.

How to use this tool

  1. Paste the token

    Paste a JWT into the Token box. A leading Bearer or Authorization: Bearer is fine, and so are line breaks from a log file. The header and payload decode as you type, and the token is split into its three colored parts so you can see where each one starts.

  2. Read the claims and times

    The Claims card lists every claim with a plain explanation. exp, nbf and iat show as real dates in your time zone or UTC, with how long ago or from now each one is. The Time claims card at the top says whether the token is inside its time window right now.

  3. Add the key to check the signature

    Until you add a key, the signature stays Unverified. For HS256, HS384 and HS512, paste the shared secret. For RS, PS, ES and EdDSA tokens, paste the issuer's public key as a PEM block, a JWK, or the whole JWKS. The tool picks the key that matches the token's kid.

  4. Read what was and wasn't checked

    A passing check turns the Signature card green and lists exactly what it proved: this key signed this header and payload. It also lists what's still up to your server, like checking iss, aud and permissions. Clear the token and key when you're done.

About this tool

A JSON Web Token is three Base64url parts joined by dots: a header that names the signing algorithm, a payload of claims about a user or a client, and a signature over both. This decoder splits a token apart, shows the header and claims as formatted JSON, and turns the exp, nbf and iat timestamps into dates you can read at a glance.

Reading a token is the easy half. Anyone can write one, so the tool keeps the signature marked Unverified until you give it the issuer's key and Web Crypto confirms the signature matches. It also keeps the two questions apart: whether the signature is good, and whether the token is inside its time window right now.

What it checks

Structure: three parts, strict Base64url with no padding, and a JSON object in both the header and the payload. Times: exp and nbf against your clock, with optional leeway, and iat in the future as a warning. Signatures: HMAC, RSA, RSA-PSS, ECDSA and Ed25519 with the key you supply. It also explains header fields like kid, jku and jwk, and it never fetches a key URL or trusts a key the token carries.

When to use it

Debugging a 401 from an API, checking why a login session ends early, reading the scopes in an OAuth access token, or confirming that a token from your auth provider is signed by the key in its JWKS. Pair it with the Unix Timestamp converter for other epoch times and the Encoding Converter when you need the raw bytes of a Base64url part.

How tokens are signed, checked and broken, with the claims and algorithms you'll meet in real APIs.

Frequently asked questions

Is it safe to paste a JWT into this decoder?
The token and key stay in your browser tab. Decoding and signature checks run in JavaScript with the browser's own Web Crypto API, and nothing is sent to a server, saved to storage, or put in the page address. Share links never include them, and session recordings block the whole tool. Still, treat a live production token like a password: it works for anyone who holds it until it expires.
What's the difference between decoding and verifying a JWT?
Decoding only reads the Base64url text, so anyone can do it without a key. Verifying recomputes the signature with the right key and checks that it matches. A decoded token proves nothing on its own, because anyone can write a token that claims to be an admin. That's why this tool shows Unverified until a real signature check passes.
Why does my token say it's expired?
The exp claim is a Unix time in seconds, and RFC 7519 says the current time has to be before it. If the token looks fresh but still fails, check three things: the server's clock, whether exp was written in milliseconds by mistake, and whether your library allows any leeway. The Time settings let you try a leeway of up to 5 minutes to see if clock drift is the cause.
Which algorithms can it verify?
HS256, HS384 and HS512 with a shared secret, RS256, RS384 and RS512 and the PS versions with an RSA public key, ES256, ES384 and ES512 with an EC public key, and EdDSA with an Ed25519 key. Tokens with alg none are flagged as unsigned and never verified. Encrypted tokens (JWE, five parts) can't be read without the decryption key, so the tool says so instead of guessing.
Does a verified signature mean the token is valid?
It means the key you pasted signed exactly this header and payload. Your server still has to check that the key really belongs to the issuer, that iss and aud match what it expects, that the token isn't expired or revoked, and that the claims allow the request. The tool lists those checks next to every passing result.
Why won't it use the public key as my HS256 secret?
That's the algorithm confusion attack. If a server lets the token's header pick HS256 while it holds an RSA public key, an attacker can sign a forged token with the public key text as the HMAC secret. The tool only checks HS tokens with a shared secret and RS, PS, ES and EdDSA tokens with a public key, the same rule a safe verifier follows.