JWT Decoder Guide
Decode shows you the JSON. Verify tells you whether the key you hold signed it. Your API still has to enforce the claims.
rookvpn.com/jwt decodes and verifies tokens in the browser. The token is a credential. Do not paste a production refresh token into a screen share or a ticket.
Decode is not verify
Anyone can build a token that base64url-decodes into a header and a payload. The decode page is for reading alg, exp, iss, aud, and sub. It does not prove those fields. If alg is none, stop. Do not teach a server to accept the algorithm written in the header.
Go to the verify page with the HMAC secret or the RSA public key that belongs to the issuer. A valid signature on an expired token is still an expired token. Check exp and nbf after the signature succeeds. Check aud is your service. A token minted for a different API does not become yours because the signature was valid.
Keys
HMAC verification needs the shared secret. RSA verification needs the public key, not the private key, and not the token. Do not take the key from the same email that contained the token. Pin the algorithm you accept so a token cannot switch RS256 to HS256 and ask you to treat the public key as an HMAC secret.
The payload is readable. A JWT is not encryption. Do not put a password or a private key inside a claim.
Claims you actually enforce
exp is Unix time. Compare it to a clock, not to a calendar year copied from the integer. aud is the audience. Missing claims that your policy requires are a reject, not a field you fill in from a header sitting beside the token.
The claims write-up on rookvpn.com/jwt/jwt-claims-explained and the pitfalls on rookvpn.com/jwt/jwt-security-best-practices are the two pages to keep open while you change server code.