JWT Decoder, Verifier & Security Inspector

Frequently Asked Questions

• What's the difference between decoding and verifying a JWT?

  Decoding a JWT simply base64-decodes the three segments (header, payload, signature) so you can read the contents — no secret key is needed. Verifying a JWT cryptographically validates that the signature matches the header and payload, ensuring the token wasn't tampered with. Verification requires the correct secret (for HMAC algorithms like HS256) or public key (for RSA/ECDSA algorithms like RS256). You can decode any JWT without verifying it, but you should never trust a decoded token until you've verified its signature.

• Is it safe to decode a JWT? Will my secret key be exposed?

  Yes, it is safe to decode a JWT in a browser-only tool like this one. Decoding only reads the base64-encoded JSON — no secret key is involved, so nothing can be exposed. Your secret key is only required during verification, and this tool never sends your secret or token data to any server. Everything runs locally using the Web Crypto API. However, never paste a JWT containing sensitive data you wouldn't want visible on your screen, since the decoded payload is displayed in plain text.

• What's the difference between RS256 and HS256?

  RS256 is an asymmetric algorithm (RSA) that uses a private key to sign and a public key to verify — the public key can be shared freely. HS256 is a symmetric algorithm (HMAC) that uses the same shared secret for both signing and verification. RS256 is preferred for server-to-server communication because the signing key stays private and tokens can be verified by any service holding the public key. HS256 is simpler but requires every verifier to share the same secret, making key distribution a security risk.

• How do I check if a JWT has expired?

  Look at the exp (expiration time) claim in the decoded payload — it's a UNIX timestamp in seconds. Compare it to the current time; if the current UNIX timestamp exceeds the exp value, the token is expired. This tool automatically detects expiration and displays a visual timeline showing when the token was issued, when it becomes valid (nbf), and when it expires. If no exp claim is present, the token never expires, which this tool flags as a security concern.

• What's the difference between an access token and an ID token?

  An access token is used to authorize API requests — it tells a server what permissions the bearer has. An ID token (typically a JWT) authenticates the user's identity and contains claims like name, email, and profile information. Access tokens are opaque to clients and should not be read for user data; ID tokens are meant to be decoded client-side. In OAuth 2.0 and OpenID Connect flows, you typically receive both: the ID token proves who the user is, and the access token grants access to resources.

• Why am I getting an 'invalid signature' error?

  An 'invalid signature' error means the JWT's cryptographic signature doesn't match the one computed from the header and payload. This usually happens when you're using the wrong secret or public key for verification. For HMAC algorithms (HS256/HS384/HS512), ensure the secret string is exactly what the issuer used. For asymmetric algorithms (RS256/ES256), verify you're using the correct public key from the issuer's JWKS endpoint. It can also occur if the JWT was modified or truncated in transit, or if the signing algorithm in the header doesn't match the one used to produce the signature.

• Can I decode a JWT without the secret key?

  Yes, you can always decode a JWT without the secret key. JWTs are not encrypted by default — they are only signed. The header and payload are base64url-encoded, which is a reversible encoding, not encryption. Any base64 decoder can read them. The secret key is only needed to verify the signature, not to read the contents. This is by design: the payload is meant to be readable by any party that receives the token. If you need confidentiality, use JWE (JSON Web Encryption) or transmit tokens over a secure channel.