Does this verify the JWT signature?

Optionally, yes. Leave the secret field empty and the tool decodes only, reporting the signature as not checked. Supply the signing secret and an HS256, HS384, or HS512 signature is verified locally with the Web Crypto API. Asymmetric algorithms such as RS256 and ES256 need a public key and are not verified yet; they are reported as unsupported rather than being checked against your secret.

Is it safe to paste a production token here?

The token is processed entirely in your browser and is never sent to tool4.dev. That said, treat any live credential carefully and rotate it if you have any doubt about where it has been.

Why is the payload not valid Base64?

JWTs use Base64URL, which uses - and _ in place of the + and / of standard Base64, and always drops the trailing = padding. RFC 7515 requires that omission, so a JWT segment is never padded. This decoder restores both the padding and the standard alphabet before decoding.

Is it safe to paste the signing secret here?

The secret is handled exactly like the token: it stays in your browser, is used only as a Web Crypto HMAC key, and is never sent anywhere or written to the URL. It is masked by default with a reveal toggle, and Clear empties the field. As with the token, treat a production secret with care regardless of where you paste it.

Why does it refuse a token whose alg is none?

An alg of none means the token carries no signature at all, so there is nothing to verify. Accepting such a token is a known authentication bypass: an attacker strips the signature, sets alg to none, and a permissive library treats the forged claims as genuine. This tool reports it as rejected rather than quietly reporting an unverified signature.

Security / LOCAL TOOL

JWT Decoder

Decode JWT headers and payloads, and verify HS256 signatures, without sending your token or key to a server.

Runs locally — input is never uploaded

InputPaste a JWT

Signing secret Optional, for HS256

ResultReady when you are

WHAT IT DOES

Read a token's claims without handing it to anyone.

Paste a JSON Web Token and its header and payload are Base64URL-decoded and formatted as readable JSON. The three dot-separated segments are split locally, so you can inspect the algorithm, issuer, subject, and expiry of a real token without it leaving your machine. Add the signing secret and the HS256, HS384, or HS512 signature is verified in your browser with the Web Crypto API. The secret is optional: decoding never needs it, which matters when you are looking at a token you cannot verify.

Why use it?

Use it to investigate a token's claims and signature status while keeping decoding separate from authentication. Readable claims are not proof that their sender is trusted.

How to use this tool

Paste the three-part JWT and decode it without a secret to inspect its header and payload.
If you need HMAC signature verification and have the correct shared secret, enter it in the masked field and run again. Asymmetric signing algorithms are not verified here.
Review signature status separately from issuer, audience, expiry, and your application's acceptance rules. Clear the workspace when finished; never share a real token as an example.

Details and limitations

The header and payload are decoded and pretty-printed, and the signature segment is shown in full.
Signature verification is optional and reports one of three outcomes: verified, does not match, or not checked. An unchecked signature is never presented as a passing one.
The algorithm is read from the header but never trusted to pick the key type. alg: none is refused, and an asymmetric algorithm is reported as unsupported rather than being checked against your secret as an HMAC key, which is the algorithm-confusion attack.
A failed check still shows the claims, because a rejected token is exactly when you need to read them.
Malformed tokens report which segment failed rather than silently producing empty output.
Base64URL padding is reconstructed automatically before decoding.

COMMON QUESTIONS

JWT Decoder questions

Does this verify the JWT signature?: Optionally, yes. Leave the secret field empty and the tool decodes only, reporting the signature as not checked. Supply the signing secret and an HS256, HS384, or HS512 signature is verified locally with the Web Crypto API. Asymmetric algorithms such as RS256 and ES256 need a public key and are not verified yet; they are reported as unsupported rather than being checked against your secret.
Is it safe to paste a production token here?: The token is processed entirely in your browser and is never sent to tool4.dev. That said, treat any live credential carefully and rotate it if you have any doubt about where it has been.
Why is the payload not valid Base64?: JWTs use Base64URL, which uses - and _ in place of the + and / of standard Base64, and always drops the trailing = padding. RFC 7515 requires that omission, so a JWT segment is never padded. This decoder restores both the padding and the standard alphabet before decoding.
Is it safe to paste the signing secret here?: The secret is handled exactly like the token: it stays in your browser, is used only as a Web Crypto HMAC key, and is never sent anywhere or written to the URL. It is masked by default with a reveal toggle, and Clear empties the field. As with the token, treat a production secret with care regardless of where you paste it.
Why does it refuse a token whose alg is none?: An alg of none means the token carries no signature at all, so there is nothing to verify. Accepting such a token is a known authentication bypass: an attacker strips the signature, sets alg to none, and a permissive library treats the forged claims as genuine. This tool reports it as rejected rather than quietly reporting an unverified signature.