How to Decode JWT Safely

guide OpenTrojan Threat Intelligence

Decode JWTs safely without uploading them: understand what decoding reveals, why decoding is not verification, and what claims to inspect (alg, exp, iss, aud, sub) for API security review.

Quick Answer

Decode JWTs locally to inspect header and payload claims — algorithm, expiration, issuer, audience, subject — and never paste tokens into untrusted online decoders; decoding is not verification, and signatures must be validated by the API itself.

Definition

JWT (JSON Web Token) is a compact, signed claims container used for authentication and authorization flows; safe use in analysis means decoding locally and never confusing decoding with signature verification.

Answer first

Decode locally, inspect the claims, and remember: decoding ≠ verification. Signatures are validated by the server, not by a decoder.

1. Decode the header

Look at alg and typ. If an untrusted library or document shows alg: none, that is a red flag for insecure parsing.

2. Inspect the payload claims

Review exp (never trust an expired token), iat, nbf, iss, aud, and sub. Check that issuer and audience match the intended service.

3. Never upload tokens

Paste tokens only into local-only tools (or jwt.io and similar only if you trust the clipboard — better: local only). Tokens can carry privileges; treat them like passwords.

4. Remember the limits

Decoding reveals claims, not validity. A token that decodes cleanly can still be forged or expired; verification happens on the server with the signing key.

5. Continue to API security

When reviewing an API, confirm tokens are validated (signature, expiration, issuer, audience) server-side, and that secrets are never shipped in client code.

Tools that help

References

Have a follow-up question?

Ask OpenTrojan's evidence-backed assistant about this topic — answers cite their sources.

Ask AI about this Start an investigation