JWT Debugger

JWT Decrypter — Decode Any JSON Web Token

Most tokens people want to "decrypt" are signed, not encrypted — the payload is readable without any key. Paste one below to decode it.

Encoded

Paste a JWT token to inspect
HeaderPayloadSignature
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
Click to edit
Valid JWT Structure

Decoded

Inspect claims & verify signature
Header
Payload (read-only)
Signature Verificationoptional
HMAC secret

Decrypting vs. decoding a JWT

If a token has three dot-separated parts, it is a JWS — a signed token. Its payload is base64url-encoded, which is an encoding, not a cipher. Anyone who holds the token can read every claim inside it without a key, which is precisely what the tool above does. The signature does not hide the contents; it only proves they have not been changed since the issuer signed them.

Genuinely encrypted tokens use JWE (RFC 7516) and have five parts. Their ciphertext is unreadable without the recipient’s decryption key, so no browser tool can open one for you.

How the two token types compare
 JWS (signed)JWE (encrypted)
Parts35
Payload readable without a keyYesNo
GuaranteesIntegrity, authenticityIntegrity, authenticity, confidentiality
Header fieldsalgalg and enc
Typical useAccess tokens, ID tokens, API authTokens carrying data that must stay private

The practical consequence: never put anything confidential in a signed token’s payload. Store an opaque identifier and keep the sensitive data server-side, or reach for JWE if the contents genuinely must travel encrypted.

Frequently asked questions

Usually there is nothing to decrypt. The common JWT is a JWS — a signed token whose payload is base64url-encoded, not encrypted. Decoding it requires no key at all, which is exactly what this page does. Only a JWE token is genuinely encrypted, and that does require the recipient’s key.

Count the dot-separated parts. A signed JWS has three (header, payload, signature). An encrypted JWE has five (header, encrypted key, initialisation vector, ciphertext, authentication tag). You can also check the header: a JWE carries an "enc" field alongside "alg".

No. Decoding needs no key whatsoever — the header and payload are plain base64url. A key is only needed to verify the signature, which proves the token has not been tampered with. Decoding and verifying are separate steps, and this tool does both.

It is only a problem if you put confidential data in the payload. Signed tokens guarantee integrity, not confidentiality. Treat the payload as public: store identifiers rather than personal data, and if the contents genuinely must be hidden, use JWE encryption or keep the data server-side.

JSON Web Encryption is the standard for tokens whose contents are actually encrypted, defined in RFC 7516. A JWE has five parts and its payload is unreadable without the correct decryption key. It is far less common than JWS in practice, since most systems only need tamper-evidence.