A JSON Web Token looks like noise but is mostly readable: two of its three parts are just base64-encoded JSON. This decoder opens them so you can see who the token is for, what it claims, and exactly when it expires — usually while working out why a request is being rejected. It can also check an HMAC signature if you have the secret, which tells you whether the token was really issued by the system you think. Tokens carry live credentials, so it matters that this runs in the page: neither the token nor the secret is transmitted anywhere.
Safer than most places, because the decoding happens in your browser and nothing is sent over the network. Still treat the token as the credential it is: anyone who sees your screen or clipboard has it, and if it is a live session token, it stays valid until it expires.
No, and this surprises people. The header and payload are only base64-encoded — anyone holding the token can read them without a key. The signature stops the contents being changed, not read. Never put anything secret in a JWT payload.
Those are signed with a shared secret, which you can paste in. RS256, ES256 and the rest are signed with a private key and verified with the matching public key, which usually has to be fetched from the issuer's JWKS endpoint — that would mean sending a request, which this tool does not do.
Most often the secret is not the one used to sign, or it was pasted with a stray space or newline. It can also mean the token was signed with a different algorithm than its header claims, or that it was tampered with — which is exactly the case verification exists to catch.
They are standard time claims, all Unix timestamps in seconds. exp is when the token stops being valid, iat is when it was issued, and nbf is the earliest time it may be used. This page shows all three as ordinary dates and flags a token whose exp has passed.