JWT Parser

How JWT parsing works

A JWT is three Base64Url segments: Header.Payload.Signature. The tool decodes the first two into JSON locally and converts timestamps like exp/iat/nbf to human-readable time. The signature is only shown, not verified in the browser, and nothing is uploaded.

• exp/nbf are Unix second timestamps; the tool renders them in local time so you can check expiry.
• The payload is only Base64-encoded, not encrypted, so anyone can decode it; never put plaintext passwords or secrets there.

FAQ

1. Why are non-English characters corrupted inside the decrypted Payload?

This happens if the token serializer was compiled using non-standard Base64URL string tables. Our tool uses UTF-8 sequences. Ensure your backend uses standard string schemes.

2. Can this client-side parser verify if a signature is valid?

Yes. If you paste your HMAC secret key or RSA public key into the checker card, it calculates and compares the signature block offline.

3. Does parsing JWT tokens send authorization Bearer tokens to a remote server?

No! Decoding is purely splitting string dots and calling Base64URL decoding in local JS memory. Tokens are never transmitted to any third-party.

4. How can I quickly check if a JWT token has expired?

The parser auto-converts the `exp` (expiration) and `nbf` (not-before) Unix timestamps into human-readable date-time strings, highlighting whether the token is active or expired.

5. What do the three sections of a JWT (Header, Payload, Signature) represent?

Header defines the algorithm & token type; Payload contains claims like user IDs, roles, and timestamps; Signature guarantees data authenticity.

6. Why can anyone decode Payload claims without supplying a secret key?

JWT payloads are Base64URL encoded, not encrypted. Anyone holding the token can decode it. Never store unencrypted passwords or secrets inside JWT payloads.