How to safely decode a JWT and why decoding is not validation

What decoding actually does

A compact JWT is three Base64URL segments: header, payload, signature. Decoding the first two is a text operation. Anyone can do it, including ConvertPass in your browser, including an attacker who never had your key.

Validation is a different job. It needs the correct key, an algorithm allow-list, and checks for exp, nbf, iss, aud, and replay. A website that offers ‘JWT verify’ either wants your secret or it is theatre.

What we tested

The decoder was tested with an unsigned alg none example, with a Bearer prefix, and with a two-segment string that is not a JWT. The unsigned example reported signaturePresent false. The two-segment string failed with a three-segment requirement. Header and payload values were shown as JSON text, including a payload that contained <script> — which rendered as text, not as a script.

eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZGEiLCJpc3MiOiJjb252ZXJ0cGFzcyJ9.

Practical rules

Paste staging tokens when you can. Production access tokens are credentials. ConvertPass does not send them, but your screen, extensions, and shared computers still exist.

If alg is none, stop. If kid looks unexpected, stop. If you need to verify, do it in your own backend with a library, not in a generic website.

Limitations

Encrypted JWTs (JWE) are not decrypted. Nested tokens must be decoded in steps. ConvertPass does not fetch JWKS.