Question 1

What is a JWT (JSON Web Token)?

Accepted Answer

A JWT is a compact, URL-safe token format defined in RFC 7519, made of three base64url-encoded segments separated by dots: a header (algorithm and token type), a payload (claims — data about a user or session), and a signature that binds the two. JWTs are widely used for stateless authentication and authorization, letting a server trust a token's claims without a database lookup, as long as the signature checks out.

Question 2

Is decoding a JWT the same as verifying it?

Accepted Answer

No, and this is the single most important thing to understand about JWTs. Decoding just reverses base64url encoding to read the header and payload — anyone can do this with no key at all. Verifying checks the signature against a secret or public key to confirm the token wasn't forged or tampered with. Never trust a claim from a token whose signature you haven't verified.

Question 3

Is it safe to use this JWT decoder with a real, live token?

Accepted Answer

Decoding is inherently safe from a confidentiality standpoint — this tool runs entirely client-side, so the token and any secret you enter for verification never leave your browser or touch a server. That said, treat any live token as sensitive: a valid, unexpired JWT can be replayed by anyone who has it, so avoid pasting production tokens into any tool, including this one, outside a controlled debugging session.

Question 4

What does alg: none mean, and why is it dangerous?

Accepted Answer

alg: none is a legitimate value in the JWT specification meaning the token is intentionally unsigned. It becomes a serious vulnerability when a library or application accepts a none-algorithm token as if it were verified — an attacker can take any valid JWT, change the claims, set alg to none, drop the signature, and have it accepted. This tool flags none-algorithm tokens explicitly so you can catch this misconfiguration during debugging or a security review.

Question 5

Can this tool verify an RS256 or ES256-signed JWT?

Accepted Answer

Not directly. RS256, ES256, PS256 and similar are asymmetric algorithms — verification requires the issuer's public key, which this tool has no interface for since it isn't something you'd typically have on hand for an arbitrary token. Signature verification here is limited to the symmetric HMAC family (HS256, HS384, HS512), where verification only needs the same shared secret used to sign the token.

Question 6

What's the difference between exp, nbf, and iat?

Accepted Answer

All three are registered claims holding Unix timestamps (seconds since epoch). iat (Issued At) records when the token was created. nbf (Not Before) marks the earliest moment the token becomes valid — useful for pre-issued, delayed-activation tokens. exp (Expiration Time) is the deadline after which the token must be rejected. A verifier should always check exp and, if present, nbf — not just trust that a token 'looks' current.

Question 7

Should I ever put a secret or password in a JWT payload?

Accepted Answer

No. The payload is base64url-encoded, not encrypted, so anything you put there — API keys, passwords, personal data — is trivially readable by anyone who intercepts or is handed the token, exactly as this decoder demonstrates. Keep payloads to non-sensitive identifiers and claims. If a token genuinely needs to carry confidential data, use a JWE (JSON Web Encryption) construction instead of a plain signed JWT.

JWT Decoder

Why Use This JWT Decoder?

How to Use the JWT Decoder

Frequently Asked Questions

Why Use This JWT Decoder?

How to Use the JWT Decoder

Frequently Asked Questions

Related Tools