JWT Decoder & Encoder

A JSON Web Token (JWT) is a compact, self-contained way to transmit information between parties as a signed JSON object. You'd need to decode one when debugging an authentication flow — to check what claims are inside, whether the token has expired, what algorithm signed it, or why a protected route is rejecting it.

The decoding runs entirely in your browser. No data is sent to a server or stored anywhere. That said, for production tokens that carry sensitive information, use this in a private browsing session and avoid pasting them into any tool you haven't verified. Development and test tokens are fine.

The tool supports HS256, HS384, HS512 (HMAC with SHA), and RS256 (RSA with SHA-256). These cover the vast majority of JWT implementations in the wild.

Paste the full JWT string — all three dot-separated parts — into the input field and select Decode. The header and payload appear as formatted JSON immediately.

Decoding reads the contents of the token without checking whether it's valid. Anyone can decode a JWT because the payload is only Base64URL-encoded, not encrypted. Verification is different — it uses the secret key or public key to confirm that the signature is valid and the token hasn't been tampered with. This tool does decoding; signature verification requires the key.

JWTs must have exactly three segments separated by dots. The most common causes of this error are: extra whitespace or line breaks in the pasted token, a truncated token (check that you copied the whole thing), or a value that's a session ID or opaque token rather than an actual JWT.

Yes. The header and payload are a direct Base64URL decode of what's in the token. There's no interpretation or transformation — if the token says exp: 1700000000, that's what you'll see (along with the converted human-readable date).

Yes, that's exactly what the encoder is for. Specify your claims, choose your algorithm, enter your secret, and generate a signed token you can use in Postman, curl, or your integration tests.

No. Everything runs client-side in your browser. Nothing is transmitted to a server. Your tokens are never stored, logged, or shared.

JWTs have an exp (expiration) claim that contains a Unix timestamp. If the current time is past that timestamp, the token is expired. This is working as designed — your application should reject expired tokens. To fix it, generate a new token with a future exp value, or adjust the expiration logic on your auth server.