A JSON Web Token is not an identifier. It is a bearer credential, which means whoever holds it can act as the subject it describes until it expires. Pasting one into a web page is therefore closer to pasting a password than to pasting a log line, and the usual reassurance — that the payload is only base64, not encryption — misses the point entirely. The payload being readable is exactly why the token is dangerous to hand over.
The practical question is whether the page sends the token anywhere. A decoder that posts your token to its own backend has, for the lifetime of that token, everything it needs to impersonate you against the issuing API. That lifetime is often longer than people assume: access tokens of an hour are common, refresh tokens can run for weeks, and a token minted for a service account may not expire at all. The window is not theoretical.
You can tell the two apart without trusting anyone's marketing copy. Open your browser's developer tools, switch to the Network tab, clear it, then paste a token and decode. If a request appears carrying the token in its URL, body or headers, the tool is server-side. If the tab stays empty, the decoding happened in the page. This check takes about fifteen seconds and is more reliable than any claim on the page, including ours — run it here if you like.
When a token has already gone somewhere you did not intend, treat it as compromised rather than probably fine. Revoke or rotate it at the issuer, the same way you would a leaked API key, and check the audit log for the period between the paste and the revocation. Reasoning about whether anyone actually looked is not a control; revocation is.
There is a narrow case where pasting is genuinely fine: a token that is already expired, or one you minted yourself for a test with no real subject and no real audience. Expiry is the cleanest signal, and it is the first thing worth reading — a token past its `exp` claim cannot be replayed, so the question stops mattering. Decoding it locally tells you that in one step.