What does verification actually check?
Two separate things, reported separately. The signature check recomputes the HMAC over the header and payload with the secret you supply and compares it with the one in the token, which tells you whether the claims were edited after signing. The expiry check reads the 'exp' claim against the current time. A correctly signed token can be long out of date, and an in-date token can be forged, so neither answer stands in for the other.
Why is my verification failing?
Usually the secret is not the one the token was signed with, the token was copied with a character missing or a line break inserted, or the service signs with a different HMAC digest than the one selected here. Because expiry is reported on its own row, an expired token still shows whether its signature is genuine, which narrows this down quickly.
Can I decode a token without verifying it?
Yes, and that happens by default. The header and payload are decoded and shown the moment you paste, with no secret involved — reading what is inside a token needs no key. The secret only adds the signature verdict; the decoded claims above it do not change.
Is it safe to paste a real token here?
The token and the secret are used in your browser and are not sent anywhere. A token is still a credential while it is valid, so the usual care applies to where you copied it from and who is looking at your screen — but nothing here transmits or stores it.
What information is in a JWT payload?
Typically a subject ('sub'), an expiry ('exp'), an issued-at time ('iat') and an issuer ('iss'), plus whatever custom claims the application added. None of it is encrypted; Base64url is an encoding, not a secret, which is why anything genuinely confidential does not belong in a token.
