JWE Encryption

Encrypt a payload as a compact JWE

This page builds a compact JWE — five Base64URL segments, header.encrypted_key.iv.ciphertext.tag — from the text you enter and the recipient key you supply. Everything runs in your browser; nothing is uploaded.

A JWS only signs its payload, and anyone holding the token can read it. A JWE hides the payload: only the holder of the matching private key, shared secret, or password can decrypt it. The plaintext is used exactly as typed and encoded as UTF-8. Paste a JSON claims set such as {"sub":"user","exp":1700003600} to produce an encrypted JWT.

How to encrypt

1. Enter the plaintext.
2. Choose the Algorithm (alg), which decides how the content key reaches the recipient, and the Encryption (enc), which encrypts the plaintext itself.
3. Choose the key type and paste the key:
   • UTF-8, Hex, or Base64 — the shared secret for dir, A*KW, and A*GCMKW, or the password for PBES2-*. Base64 accepts both the standard and the URL-safe alphabet, with or without = padding.
   • Pem Text — the recipient’s RSA public key for RSA-OAEP*, or EC / X25519 public key for ECDH-ES*. An unencrypted private key works too; only its public part is used. This page has no passphrase field, so an encrypted private key is refused — paste the public key instead.
   • JWK — the recipient’s public JWK, or "kty": "oct" for the symmetric algorithms. A whole JWK Set is not accepted here: pick the recipient’s key out of it yourself, and copy its kid into the Header so the recipient can find the matching private key.
4. Edit the Header JSON for kid, cty, zip, or anything else your recipient expects. alg and enc are always overwritten with the selected values.
5. Encrypt, then use the swap button to send the token to JWE Decryption and open it with the matching private key, secret, or password.

Every run produces a different token even with the same input and key: the content key and IV are random each time, and so are the ephemeral key for ECDH-ES and the salt for PBES2.

Choosing the algorithm

Algorithm (alg)	Key	Notes
RSA-OAEP, RSA-OAEP-256, RSA-OAEP-384, RSA-OAEP-512	RSA public key, 2048 bits or more	The usual choice when the recipient publishes an RSA key. Prefer RSA-OAEP-256.
ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A256KW	EC public key on P-256, P-384, P-521, or X25519	Smaller keys and tokens than RSA. Plain ECDH-ES uses the derived key directly and leaves the encrypted key segment empty.
A128KW, A256KW	16 or 32-byte shared secret	AES Key Wrap of a random content key.
A128GCMKW, A256GCMKW	16 or 32-byte shared secret	Wraps the content key with AES-GCM; iv and tag are added to the header.
PBES2-HS256+A128KW, PBES2-HS512+A256KW	Password	Derives the wrapping key with PBKDF2; set the iteration count in PBES2 Count.
dir	Shared secret the size of the content key	The secret is the content key itself: 16 or 32 bytes for A128GCM or A256GCM, and 32 or 64 bytes for A128CBC-HS256 or A256CBC-HS512.

For the content encryption (enc), A256GCM is the default and a good fit almost everywhere. The A*CBC-HS* family exists for systems without AES-GCM; it pairs AES-CBC with an HMAC tag and is just as safe when implemented as specified.

RSA1_5 is deliberately not offered. It is vulnerable to padding-oracle attacks and has been deprecated for new designs.

The 192-bit variants (A192KW, A192GCMKW, ECDH-ES+A192KW, PBES2-HS384+A192KW, A192GCM, A192CBC-HS384) are not offered. They need 192-bit AES, which Chrome and Edge leave out of Web Crypto, and the 128- and 256-bit variants cover the same ground.

PBES2 Count

PBES2-* stretches the password with PBKDF2 p2c times before using it, so a larger count makes guessing a weak password slower. The default is 600,000; this page accepts 1,000 to 1,000,000 so every token it makes can also be opened by JWE Decryption. A password-based JWE is only as strong as the password, so use a long random one.

Keep production keys out of here

Encryption only needs the recipient’s public key, so there is rarely a reason to paste a private key on this page. Remember Input stores the plaintext, key, and header in your browser’s local storage, and Share encodes them into a link. Both are opt-in and neither reaches a server, but a link built from a real secret carries that secret. Create a test pair with RSA Key Generator or ECDSA Key Generator — an EC key pair works for ECDH-ES as well.

Related tools

• JWE Decryption for the other half of the round trip
• JWS Sign Message to sign rather than encrypt
• JWT Decoder to inspect a signed token without a key

JWE encryption FAQ

Does the plaintext have to be JSON?

No. JWE encrypts arbitrary bytes. JSON is only needed if the result should be an encrypted JWT.

Can I sign and then encrypt (a nested JWT)?

Not in one step. Sign the claims on JWS Sign Message, paste the resulting token here as the plaintext, and add "cty": "JWT" to the Header so the recipient knows a signed token is inside.

Why does the output change every time?

The content key and IV are generated fresh for every token, as the specification requires. Reusing them with AES-GCM would break its security.

What does “zip” do?

Adding "zip": "DEF" to the Header compresses the plaintext with DEFLATE before encrypting it. Use it only for large payloads you control: compressing secrets next to attacker-chosen text can leak the secret through the ciphertext length.

Why is my output empty?

An empty plaintext produces no token. Errors appear in the output box, for example Key is blank., a key length that does not match the algorithm, or a key type that does not suit it.