Decoding a JWT does not verify its signature

Short answer

Decoding a JWT only turns its Base64URL segments into readable information. It does not prove that the issuer is authentic, the signature is valid, or the token should be accepted. Before authorizing anything, the server must verify cryptography, algorithm, issuer, audience, and time claims under its own policy.

What a decoder does

A signed JWT in compact form commonly has three segments:

header.payload.signature

The first two can be decoded without a key. Anyone can therefore read—and also create—a header and payload claiming, for example, "role":"admin". Seeing that data on screen says nothing about whether the third segment contains a signature from the expected issuer.

Tools in a Tab’s JWT decoder is for local inspection of structure and claims. It explicitly states that it does not verify signatures. Avoid pasting production tokens into services you do not control; a token may reveal identifiers or permissions even when its contents are not encrypted.

What the relying system must verify

RFC 8725 collects JWT security best practices. Important checks include:

• allow only expected algorithms instead of trusting the token’s choice;
• verify the signature with the correct key;
• require iss to identify the expected issuer;
• require aud to include the correct recipient;
• enforce exp, nbf, and protocol-specific claims;
• use mutually exclusive validation rules for JWT types that must not be mixed.

A maintained library can perform these operations, but only with a secure configuration. “The function returned no error” is not enough unless you know which algorithms, keys, and claims it required.

A correct diagnostic flow

If a payload says exp is 1786204800, the Unix timestamp converter can explain the date. That conversion only interprets the number. Actual acceptance requires a verifier to confirm the signature first and then compare exp with the server’s clock and allowed tolerance.

Practical rule

Decode to inspect and debug. Perform complete cryptographic verification in the component making the decision before you trust the data. Never grant access from claims that were merely read from a payload.