A JSON Web Token is three pieces of base64 with dots between them, and the first two are not encrypted: anyone holding one can read every claim in it. That is also why pasting a live token into a decoding website is a bad idea, because the token is the credential. This reads it here, says what is wrong with it, and will check the signature against your key or secret without either of them leaving the tab.
Header
Payload
Signature
A token is a credential, not a document. Whoever holds one can act as whoever it was issued to, until it expires. Every decoding site is honest until it is breached, and then it is holding a pile of other people's live sessions. This one cannot be, because nothing is sent: read the network tab while you use it.
It checks the things that actually go wrong. An algorithm of "none", which asks the other end to skip verification. A shared-secret algorithm where a key pair was expected, which is the confusion attack. A header that points at a URL for its own key. An expiry already past, or none at all. Personal details sitting in a payload that anyone holding the token can read.
The signature check happens here too. Paste the shared secret for an HS token or the public key for an RS, PS or ES one, and your browser's own crypto does the check. A private key is refused with an explanation, because a signature is verified with the public half and a private key should not be pasted into anything.
Reading a token proves nothing about whether it is valid. The claims are just text until a signature is checked against a key you trust. A token can say it was issued by anyone and can claim any role; only the signature makes that true, which is why the check is offered rather than assumed.
It cannot read an encrypted token. A JWE has five parts and its contents are encrypted, which is the point of it. Paste one and the page says so rather than pretending to fail.
Safer than anywhere else, because nothing leaves the tab: the decoding, the audit and the signature check all run in your browser. Turn the network off and the page works exactly the same. That said, a token in a browser tab is still a token on a screen, so treat the room you are in accordingly.
That the token asks to be accepted without a signature. It exists in the specification for tokens that are already protected some other way, and it has caused a long line of vulnerabilities in libraries that honoured it by default. If you did not issue a token like that, treat it as an attack rather than a mistake.
An issuer signs with a key pair, so verifiers hold its public key. An attacker changes the header to HS256 and signs a token using that public key as if it were a shared secret. A verifier that picks its algorithm from the token rather than from its own configuration will accept it. That is why an HS token from an issuer that normally uses RS or ES is flagged here.
Because the payload of a token is plain text to everyone who handles it: every proxy log, every browser it is stored in, and anything it is ever pasted into. Names, addresses and phone numbers in a token travel further than people expect.
It checks HS256, HS384 and HS512 with a shared secret, and RS, PS and ES with a public key, using your browser's own cryptography. EdDSA is not supported by every browser's crypto yet, and the page says so rather than guessing.