Private by design: tokens, keys and passwords never leave your browser
JWE decoder, encoder & editor
Inspect and decrypt JSON Web Encryption tokens, and create or re-encrypt them. Supports RSA-OAEP, ECDH-ES, AES Key Wrap, AES-GCM, direct keys and passwords, with PEM, JWK and JWKS keys.
Encrypted token (JWE)
Structure
- Protected header44 bytesJSON, authenticated as AAD
- Encrypted key40 bytesCEK wrapped with AES Key Wrap
- Initialization vector12 bytesrandom, per token
- Ciphertext115 bytessame length as the plaintext
- Authentication tag16 bytesdetects any change
Protected header
{
"alg": "A256KW",
"enc": "A256GCM",
"typ": "JWT"
}Decrypt
A256KW needs exactly 32 bytes (256 bits).
Decrypting…
Tools
Anatomy of a JWE
A compact JWE is five Base64URL-encoded parts joined by dots. The contents are encrypted with a one-time key, and that key is in turn encrypted (or agreed) for the recipient, so only they can read it.
Protected header
Which algorithms were used: alg (how the key is delivered) and enc (how the content is encrypted). Readable, but authenticated.
Encrypted key
A fresh random content encryption key (CEK), encrypted for the recipient. Empty with dir and ECDH-ES, where both sides already know or derive it.
IV
A random initialization vector, so the same plaintext never encrypts the same way twice.
Ciphertext
The plaintext (often JSON claims or a signed JWT) encrypted with the CEK.
Authentication tag
Proves the ciphertext and header haven't been changed. Decryption fails if a single bit differs.
BASE64URL(header).BASE64URL(encrypted key).BASE64URL(IV).BASE64URL(ciphertext).BASE64URL(tag)Frequently asked questions
Is it safe to paste my token and key here?+
Decrypting and encrypting both happen in your browser with the Web Crypto API. Tokens, keys and passwords are never sent to a server. Still, treat production private keys with care: anyone holding one can read every token encrypted for it.
What's the difference between a JWT and a JWE?+
A normal JWT is signed (a JWS): anyone can read its claims, but no one can change them without the key. A JWE is encrypted: only the holder of the right key can read its contents. To get both, sign a JWT and then encrypt it as the plaintext of a JWE, a "nested JWT". This decoder unpacks those too.
Which algorithms are supported?+
Key management (alg): RSA-OAEP, RSA-OAEP-256/384/512, ECDH-ES and ECDH-ES+A128KW/A192KW/A256KW (P-256, P-384, P-521 and X25519), A128KW/A192KW/A256KW, A128GCMKW/A192GCMKW/A256GCMKW, dir, and PBES2-HS256+A128KW/HS384+A192KW/HS512+A256KW. Content encryption (enc): A128GCM, A192GCM, A256GCM, A128CBC-HS256, A192CBC-HS384 and A256CBC-HS512. Compressed (zip: DEF) tokens work too. Chrome and Edge don't support 192-bit AES, so those need Firefox or Safari.
What key formats can I use?+
For RSA and EC: PEM public or private keys (SPKI, PKCS#8, PKCS#1, SEC1), X.509 certificates, JWKs, or a whole JWKS (the key matching the token's kid is picked). For AES and dir: the raw key as Base64URL, or an "oct" JWK. For PBES2: any password.
Why doesn't RSA1_5 work?+
RSA1_5 (RSAES-PKCS1-v1_5) is vulnerable to padding-oracle attacks and is deprecated. Browsers' Web Crypto API doesn't offer it, so this site can't decrypt it. Use RSA-OAEP-256 instead.
Why does the encrypted token change every time?+
Each encryption picks a new random content encryption key (CEK) and IV, and ECDH-ES also makes a new ephemeral key pair. So encrypting the same plaintext twice gives two different tokens that both decrypt to the same thing. That's on purpose: it stops anyone telling that two tokens hold the same data.