JWT Decoder: Header Payload Signature

Yes. The payload of a JWT is only Base64Url encoded, not encrypted. Base64Url is a reversible encoding used to make binary-safe text - it provides no confidentiality. Anyone who obtains the raw token string can split it on the two periods, take the middle segment, and decode it with a simple atob() call to read every claim inside it.

This is exactly what this tool does - and it is by design. JWTs use signing (JWS) to guarantee integrity and prove the data was not modified, but they do not hide the data. Always transmit JWTs over HTTPS to prevent interception in the first place. If you need the payload contents to remain confidential even if intercepted, use JSON Web Encryption (JWE) rather than plain JWS.

When a server receives a JWT, it performs the following steps. First, it splits the token on the periods to extract the three segments. Second, it Base64Url-decodes the header to learn which algorithm was used (alg field). Third, it takes the raw encoded header and encoded payload strings and joins them with a period, forming the "signing input." It then runs that signing input through the same algorithm using the same secret key (for HMAC) or the matching public key (for RSA/ECDSA), producing a candidate signature.

Finally, it compares the candidate signature against the signature in the token's third segment using a constant-time comparison (to prevent timing attacks). If they match, the token is valid. If even one character differs - because the payload was tampered with or the wrong key was used - the verification fails and the server returns a 401 Unauthorized response.

Two reasons. First, as explained above, the payload is not encrypted. Anyone who obtains the JWT - whether through a network intercept, a log file, or a misconfigured frontend - can read everything in the payload. Passwords in plaintext inside a token are instantly exposed.

Second, passwords should never be stored or transmitted in cleartext in any form, even inside an encrypted token. The correct practice is to hash passwords using a one-way function like bcrypt or Argon2, and only store the hash. If you need truly private data inside a token, use JWE for encryption in addition to JWS for signing, and still keep passwords out of tokens entirely.

Authentication answers: who are you? It is the act of verifying identity, typically by checking a credential like a username and password. When you type your password into a login form, the server is performing authentication.

Authorization answers: what are you allowed to do? After identity is established, authorization determines which resources and actions the verified user can access. JWTs are primarily an authorization mechanism. After a user authenticates once, the server issues a signed JWT encoding the user's ID, role, and permissions. On every subsequent request, the server verifies the JWT to authorize the action without re-querying a password database. The token carries the proof of what you are allowed to do - not who you are in an absolute sense. Confusing the two is a common source of security design errors.

Yes, for this tool specifically. All decoding is 100% client-side: it runs locally in your browser using plain JavaScript with no external libraries. Your JWT string is never sent to any server, never logged, and never stored. Open your browser's network tab (F12) while using this page and you will see zero outbound requests when you paste a token.

That said, apply common sense with live production tokens. If a token grants active access to a production system, revoke it after debugging rather than pasting it into any tool - including this one - and leaving it in your clipboard or browser history. A valid, unexpired JWT is a functional credential for whatever it authorizes, regardless of who holds it.