Read the header and payload of a token, with the timestamps in plain English. Decode only.
This runs entirely in your browser. Nothing you paste, type or drop here is sent anywhere — there is no server on the other end of it.
A JSON Web Token is three base64url segments joined by dots: a header saying how it was signed, a payload of claims, and a signature over the first two. The payload is encoded, not encrypted — anyone holding the token can read every claim in it. This decoder shows you what is in yours, resolves the timestamp claims into dates you can actually read, and stops there.
No, and that is on purpose. Verifying means handing a web page your signing secret or private key, and the one habit worth building around JWT debuggers is never to do that. Decoding tells you what the token claims; verifying whether it is genuine belongs in your own code, with your own keys.
No. The decoding happens in your browser and nothing is uploaded — there is no server on the other end of this page. That said, a token in your clipboard is a live credential until it expires, so treat it like a password regardless of where you paste it.
Usually one of three things: exp has passed, aud does not name the service you are calling, or the service is verifying against a different key than the one that signed it. The first two are visible here; the third is not, because this tool never sees a key.
Not from here. Changing any byte of the header or payload invalidates the signature, and producing a new valid signature requires the signing key. That is the entire security property of a JWT.
A standard signed JWT is not. Signing proves the token was not altered and who issued it; it hides nothing. Never put anything in a payload that you would not be willing to show the person holding the token.