ToolVault

Symptom: decoder says "signature invalid"

You paste a JWT (JSON Web Token) into a decoder to inspect its payload, and the tool reports:

signature invalid

or flags it red as "verification failed". You wonder: is the token broken? Did I copy it wrong?

Short answer: the token is probably fine. The message says "verification failed", not "decoding failed".

Decode vs verify — know the difference

This is the key:

| Action | Needs secret? | What it does | Can it fail? | |---|---|---|---| | Decode | ❌ No | Base64URL-restores the three parts (header.payload.signature) into plain JSON | Almost never (unless malformed) | | Verify | ✅ Yes | Recomputes the signature with the secret and compares it, confirming integrity | Fails on key/algorithm mismatch |

Decoding is "open the envelope and read" — anyone can do it. Verifying is "check the wax seal" — it requires the correct secret.

Why "signature invalid" appears

The tool decoded and tried to verify, and verification failed. Common reasons:

1. Only part of the token was pasted — missing the last segment, or extra spaces/newlines;
2. Algorithm mismatch — header says HS256 but the secret you supplied is for RS256 (asymmetric), or vice versa;
3. Wrong secret — the verification key is not the one the issuer used;
4. Tampered token — the payload was altered, so the signature no longer matches.

In essence: signature invalid is the security mechanism working correctly — it tells you "I cannot confirm this token's integrity", not "the token cannot be read".

How to read the payload without verifying

If you only want to debug / inspect what fields the payload carries (e.g. check exp expiry, sub user id), you do not need verification. Open the JWT Decoder on ToolVault:

1. Paste the full token into the input;
2. The tool shows the plain JSON of header and payload, directly readable;
3. It also shows verification status, but even if verification fails, the content is still visible — exactly what you need for debugging;
4. Parsed locally, the token is never uploaded.

When you actually need verification

Only these scenarios require verifying with the correct secret:

• A backend receiving a request must confirm the token was issued by a trusted party and not tampered with;
• Deciding token expiry / validity, relying on exp, nbf, etc.;
• Security auditing to validate token origin.

Front-end "just reading" is debugging — never substitute "decode succeeded" for "verify passed" as an authorization check, or forged tokens will bypass you.

FAQ

Can a token that fails verification still be used?

For inspection/debugging, yes. But any step that relies on the token for identity must verify it first. A token that fails verification should be rejected outright in business logic.

Why do some tools not show "invalid" while others do?

It depends on design. A decode-only tool won't complain; a decode+verify tool reports invalid when the secret is missing or mismatched. The content both show is identical.

Can HS256 and RS256 keys be mixed?

No. HS256 signs and verifies with the same symmetric secret; RS256 signs with a private key and verifies with a public key. Mixing them always fails verification.

Provided by ToolVault. Related tools: Base64 Encode/Decode, SHA256 Hash, Password Generator. Visit the home page for more developer tools.