Decoder + verifier

JSON Web Token Decoder & Verifier

Three base64url segments, a signature that is either real or is not, and a validity window that either includes right now or does not. This tool answers all three, offline, and shows the exact reason when the answer is no.

Real signature verificationexp, nbf, iss, aud checksSign new tokensNothing leaves your browser
JWT Token
Not verified yet
Key or secretalg:

The key is used by your browser’s crypto in this tab and is never sent anywhere.

1 × errorCtrl+↵ · Alt
Keep going

How it works

1

Paste the token

Paste it, or drop a file — even a log line: the token is picked out of it. It is split, decoded and checked for the malformed cases straight away.

2

Add the key

A shared secret in text, base64 or hex, a PEM public key, a JWK, or a whole JWKS — the entry matching the token’s kid is picked for you.

3

Verify

Press the button: the browser’s own crypto does the maths. You get valid, invalid, or the precise reason the key could not be used — never a shrug.

4

Take it further

Check the claims against what your service expects, sign a fresh token in the builder, or hand the payload to another tool in the suite.

Signatures actually checked

HS256/384/512, RS, PS and ES — including ES512 on P-521 — verified by the browser’s own Web Crypto. No server, no library, no upload.

Claims judged, not just shown

exp, nbf and iat against a clock skew you set, plus the issuer, audience and subject your service expects. Each check passes, fails, or is skipped, and says which.

A lifetime you can see

The countdown only ticks when there is a deadline to count, and the bar shows where now sits between nbf and exp.

Sign tokens, not just read them

Edit the header and payload, pick an algorithm, and sign. The result opens straight back in the inspector so you can verify what you just made.

Every key format

Secret as text, base64 or hex; PEM public keys; a single JWK; or a whole JWKS, where the entry matching the token’s kid is selected automatically.

Attacks named out loud

alg: none, an empty signature, a payload that is legal JSON but not an object, base64 that survived a URL — each is reported for what it is.

Nothing is uploaded

The token and the key are used by the crypto in this tab and are gone when you close it. There is no server side to send them to.

Hands off to the rest of the suite

Send the claims straight to JSONFlow, DiffSnap, Base64Bolt or Hash Bolt without downloading and re-uploading a thing.

jwt decoder

A decoder that can also say no

Paste a token to read it, add the key to prove it. Real signature verification with the browser’s own crypto, claim checks against what your service expects, and a builder that signs tokens back.

The browser already had the crypto

Web Crypto is a complete implementation of HMAC, RSASSA-PKCS1-v1_5, RSA-PSS and ECDSA, and it ships in every browser at no cost. Decoding, verification, claim checks and signing all run through it, in this tab, with no request to anywhere.

For the debugging session, not the demo

For the debugging session, not the demo

The questions that come up at three in the afternoon: is this 401 because the token expired or because the gateway has the wrong key? Did the client send the audience the API expects? Is that kid still in the JWKS? Paste the token, paste the key set, and get an answer with a reason attached — including for the tokens that are broken rather than merely invalid.

Tokens are credentials

A JWT usually carries an identity, and a signing secret is the thing that mints them. Neither is sent anywhere here: there is no server side to this tool, no account, no analytics on what you paste. Close the tab and both are gone, because memory in this tab was the only place they existed.

Frequently Asked Questions

QIs my token or my key uploaded anywhere?+

No. Decoding, signature verification and signing all run inside your browser through the Web Crypto API. There is no server component to send anything to, and nothing is stored between visits.

QCan it really verify the signature?+

Yes, and that is the point of this version. Paste the shared secret for HS256/384/512, or a PEM public key, a JWK or a JWKS for RS, PS and ES. The browser does the maths and the verdict is valid, invalid, or a named reason the key could not be used.

QWhich algorithms are supported?+

HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384 and ES512, plus EdDSA where the browser provides Ed25519. ES512 uses P-521, as the spec requires.

QWhat happens with alg: none?+

It is flagged as an unsecured token and verification always refuses it. A token with no signature is exactly the attack that check exists for, so it never shows a green tick.

QCan I create a token, not just read one?+

Yes. The build tab lets you edit the header and payload, pick an algorithm, generate a secret or an RSA/EC key pair on the spot, and sign. The result opens straight back in the inspector so you can verify what you produced.

QWhat do the claim checks do?+

They compare the token against what a verifier would demand: exp, nbf and iat with the clock skew you set, an optional maximum age, and the issuer, audience and subject your service expects. Each row passes, fails, or is skipped when you have not asked for it.

Related searches

jwt decoderverify jwt signaturejwt debuggerjson web tokenjwkssign a jwtjwt claimshs256 rs256
Part of the oLoveTools suite
oLoveTools

Decode, verify and sign JSON Web Tokens locally, with the reason attached.

The browser already had the crypto

Web Crypto is a complete implementation of HMAC, RSASSA-PKCS1-v1_5, RSA-PSS and ECDSA, and it ships in every browser at no cost. Decoding, verification, claim checks and signing all run through it, in this tab, with no request to anywhere.

For the debugging session, not the demo

The questions that come up at three in the afternoon: is this 401 because the token expired or because the gateway has the wrong key? Did the client send the audience the API expects? Is that kid still in the JWKS? Paste the token, paste the key set, and get an answer with a reason attached — including for the tokens that are broken rather than merely invalid.

Tokens are credentials

A JWT usually carries an identity, and a signing secret is the thing that mints them. Neither is sent anywhere here: there is no server side to this tool, no account, no analytics on what you paste. Close the tab and both are gone, because memory in this tab was the only place they existed.

jwt decoderverify jwt signaturejwt debuggerjson web tokenjwkssign a jwtjwt claimshs256 rs256

Frequently Asked Questions

Is my token or my key uploaded anywhere?

No. Decoding, signature verification and signing all run inside your browser through the Web Crypto API. There is no server component to send anything to, and nothing is stored between visits.

Can it really verify the signature?

Yes, and that is the point of this version. Paste the shared secret for HS256/384/512, or a PEM public key, a JWK or a JWKS for RS, PS and ES. The browser does the maths and the verdict is valid, invalid, or a named reason the key could not be used.

Which algorithms are supported?

HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384 and ES512, plus EdDSA where the browser provides Ed25519. ES512 uses P-521, as the spec requires.

What happens with alg: none?

It is flagged as an unsecured token and verification always refuses it. A token with no signature is exactly the attack that check exists for, so it never shows a green tick.

Can I create a token, not just read one?

Yes. The build tab lets you edit the header and payload, pick an algorithm, generate a secret or an RSA/EC key pair on the spot, and sign. The result opens straight back in the inspector so you can verify what you produced.

What do the claim checks do?

They compare the token against what a verifier would demand: exp, nbf and iat with the clock skew you set, an optional maximum age, and the issuer, audience and subject your service expects. Each row passes, fails, or is skipped when you have not asked for it.

© 2026 oLoveToolsAbout

JWTBolt | Free Online JWT Decoder, Verifier & Signer

Decode and verify JWT signatures locally with HS256, RS256, PS256, ES256 and more. Validate exp, nbf, iss and aud, paste a secret, PEM, JWK or JWKS, and sign new tokens. 100% in your browser.

What a JWT debugger owes you beyond base64

Splitting a token on dots and base64-decoding two of the three pieces is about fifteen lines of JavaScript, which is why every JWT page on the web can do it. It is also the least useful part. The questions that actually block a debugging session are whether the signature is real, whether the token is inside its validity window right now, and whether the claims say what the consuming service demands — and none of those are answered by a pretty-printed payload. This tool answers all three in the browser: signatures through the Web Crypto API with HS, RS, PS and ES algorithms; the time window against a clock skew you control; and the issuer, audience and subject compared with what you tell it to expect.

The failure modes matter as much as the happy path. A token whose payload is legal JSON but not an object used to blank the page; here it is reported as what it is. Base64 that came back from a URL with a plus sign in it, a segment that does not decode to valid UTF-8, an empty signature, alg set to none, a JWKS that simply has no entry for the token’s kid — each gets its own message instead of one generic "invalid token". And because a signing secret is a credential in its own right, none of it leaves the tab: the key you paste is handed to the browser’s crypto and to nothing else, which is also what makes the builder safe to use on a real key while you reproduce a bug.

Frequently Asked Questions

Is my token or my key uploaded anywhere?

No. Decoding, signature verification and signing all run inside your browser through the Web Crypto API. There is no server component to send anything to, and nothing is stored between visits.

Can it really verify the signature?

Yes, and that is the point of this version. Paste the shared secret for HS256/384/512, or a PEM public key, a JWK or a JWKS for RS, PS and ES. The browser does the maths and the verdict is valid, invalid, or a named reason the key could not be used.

Which algorithms are supported?

HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384 and ES512, plus EdDSA where the browser provides Ed25519. ES512 uses P-521, as the spec requires.

What happens with alg: none?

It is flagged as an unsecured token and verification always refuses it. A token with no signature is exactly the attack that check exists for, so it never shows a green tick.

Can I create a token, not just read one?

Yes. The build tab lets you edit the header and payload, pick an algorithm, generate a secret or an RSA/EC key pair on the spot, and sign. The result opens straight back in the inspector so you can verify what you produced.

What do the claim checks do?

They compare the token against what a verifier would demand: exp, nbf and iat with the clock skew you set, an optional maximum age, and the issuer, audience and subject your service expects. Each row passes, fails, or is skipped when you have not asked for it.

Related searches

jwt decoder, verify jwt signature, jwt debugger, json web token, jwks, sign a jwt, jwt claims, hs256 rs256