JWE Encrypt / Decrypt
Inspect, encrypt, and decrypt JSON Web Encryption tokens with AES-GCM and RSA-OAEP.
About JWE Encrypt / Decrypt
JSON Web Encryption (JWE) is a standard defined in RFC 7516 for representing encrypted content using JSON-based data structures. While its sibling specification JWT (JSON Web Token, RFC 7519) provides integrity protection through digital signatures, JWE provides confidentiality by encrypting the payload so that only the intended recipient with the correct decryption key can read it. A JWE token in compact serialization consists of five Base64url-encoded parts separated by dots: the JOSE header, the encrypted key, the initialization vector, the ciphertext, and the authentication tag. Together, these components carry everything needed for the recipient to decrypt and verify the content.
JWE separates key management from content encryption through a two-layer architecture. The content encryption algorithm (specified by the "enc" header parameter) encrypts the actual payload using a random Content Encryption Key (CEK) with an authenticated encryption algorithm such as AES-128-GCM, AES-256-GCM, or AES-CBC with HMAC-SHA2. The key management algorithm (specified by the "alg" header parameter) then wraps or encrypts this CEK for the recipient using one of several strategies: direct encryption ("dir") where a shared symmetric key serves directly as the CEK, AES Key Wrap ("A128KW", "A256KW") where a symmetric key encrypts the CEK, RSA-OAEP where the recipient's RSA public key encrypts the CEK, or ECDH-ES where an ephemeral Elliptic Curve Diffie-Hellman agreement derives the key. This separation allows the same encrypted payload to be targeted at multiple recipients using different key types through JWE JSON serialization.
JWE is used in scenarios where the token payload must remain confidential rather than merely tamper-proof. OAuth 2.0 and OpenID Connect implementations use JWE to encrypt ID tokens and access tokens that contain sensitive claims such as personal information, authorization scopes, or session details that should not be visible to intermediaries or browser-side JavaScript. Financial services and healthcare APIs encrypt tokens carrying regulated data like account numbers or patient identifiers. Nested JWT structures combine JWS and JWE by first signing a JWT for integrity and then encrypting the signed token for confidentiality, providing both authentication and privacy in a single compact token.
How to Use the JWE Encrypt / Decrypt Tool
- To inspect an existing JWE token, paste the compact serialization string (five dot-separated Base64url segments) into the input field and the tool will parse and display the JOSE header, encrypted key, initialization vector, ciphertext, and authentication tag.
- To decrypt a JWE token, paste the token, select the key management algorithm that matches the token's "alg" header (dir, AES Key Wrap, or RSA-OAEP), and provide the appropriate decryption key.
- For symmetric decryption (dir or AES-KW), enter the symmetric key in the key input field. Use the key generation button to create a random key of the correct length if you need one for testing.
- For RSA-OAEP decryption, paste the recipient's RSA private key in PEM or JWK format into the key field.
- To encrypt new content, switch to the Encrypt mode, enter your plaintext payload, select the key management algorithm and content encryption algorithm, provide the encryption key, and generate the JWE token.
- Review the generated or decrypted output, including the parsed header parameters that show which algorithms were used and any additional metadata.
- Copy the resulting JWE token or decrypted plaintext using the copy button for use in your application, API testing, or security analysis.
Common Use Cases
Encrypting OAuth 2.0 and OpenID Connect Tokens
Identity providers issue JWE-encrypted ID tokens and access tokens when the token payload contains personally identifiable information (PII) such as email addresses, phone numbers, or authorization details that should not be readable by client applications, browser extensions, or network intermediaries. The authorization server encrypts the token with the resource server's public key so that only the intended API can decrypt and process the claims, even if the token is intercepted or logged in transit.
Securing Sensitive API Payloads
Financial services, healthcare, and government APIs use JWE to encrypt request and response payloads containing regulated data such as account numbers, Social Security numbers, medical records, or tax information. JWE provides application-layer encryption that protects the data independently of transport-layer security (TLS), ensuring confidentiality even if TLS is terminated at a load balancer, logged by an API gateway, or the data is stored in an intermediary cache.
Building Nested JWT Structures for Signed and Encrypted Tokens
Applications that require both integrity verification and confidentiality use a nested JWT pattern: first creating a JWS (signed JWT) to authenticate the issuer and protect against tampering, then encrypting the entire JWS as the payload of a JWE token. The recipient decrypts the outer JWE layer to obtain the signed JWT, then verifies the signature to confirm authenticity. This pattern is common in inter-service communication where both the sender's identity and the payload's secrecy must be guaranteed.
Debugging and Inspecting Encrypted Tokens During Development
During development and testing of systems that produce or consume JWE tokens, developers need to inspect the token structure, verify that the correct algorithms are being used, decrypt tokens to validate the plaintext payload, and generate test tokens with known content. This tool provides a browser-based environment for these tasks without requiring custom scripts, command-line tools, or exposing sensitive keys to third-party services, since all cryptographic operations run client-side via the Web Crypto API.
Frequently Asked Questions
What is the difference between JWE and JWS (or JWT)?
JWS (JSON Web Signature) provides integrity protection and authentication by digitally signing a payload, but the payload remains readable by anyone who possesses the token since it is only Base64url-encoded, not encrypted. JWE provides confidentiality by encrypting the payload so that only the holder of the correct decryption key can read it. JWT (JSON Web Token) is a higher-level format that can use either JWS for signed tokens or JWE for encrypted tokens. A JWS token has three dot-separated parts (header.payload.signature), while a JWE token has five (header.encryptedKey.iv.ciphertext.tag). When both integrity and confidentiality are needed, a nested JWT wraps a JWS inside a JWE.
What key management algorithms does JWE support?
JWE defines several key management strategies through the "alg" header parameter. Direct encryption ("dir") uses a pre-shared symmetric key directly as the Content Encryption Key with no key wrapping. AES Key Wrap ("A128KW", "A192KW", "A256KW") wraps a random CEK with a symmetric key using the RFC 3394 algorithm. RSA-OAEP and RSA-OAEP-256 encrypt the CEK with the recipient's RSA public key. ECDH-ES performs an Elliptic Curve Diffie-Hellman key agreement to derive the CEK. ECDH-ES+A128KW combines ECDH-ES with AES Key Wrap. PBES2 derives a key from a password for password-based encryption. The choice depends on whether you have symmetric shared keys, asymmetric key pairs, or password-based access.
What content encryption algorithms are available in JWE?
The content encryption algorithm, specified by the "enc" header parameter, performs the actual payload encryption using authenticated encryption. JWE supports AES-CBC with HMAC-SHA2 combinations (A128CBC-HS256 and A256CBC-HS512) which provide 128-bit or 256-bit AES encryption with a separate HMAC for authentication, and AES-GCM variants (A128GCM, A192GCM, A256GCM) which use Galois/Counter Mode for combined encryption and authentication in a single operation. AES-GCM is generally preferred for new implementations due to its better performance and simpler construction, while AES-CBC-HS is supported for backward compatibility.
Is it safe to decrypt JWE tokens in the browser?
This tool performs all cryptographic operations client-side using the Web Crypto API, which means your tokens and keys are never transmitted to any server. The Web Crypto API provides hardware-backed cryptographic primitives implemented by the browser vendor, making it suitable for handling sensitive material in a client-side context. However, you should still exercise caution with production keys and tokens: avoid using production private keys in any web-based tool (including this one) in untrusted environments, and prefer generating test keys specifically for development and debugging purposes.
Why does my JWE token fail to decrypt?
Decryption failures typically stem from one of several causes. The most common is a key mismatch -- the decryption key does not correspond to the encryption key used to create the token. For RSA-OAEP, you must use the private key that corresponds to the public key used during encryption. For AES Key Wrap, the symmetric key must match exactly. For direct encryption, the key must be the correct length for the content encryption algorithm (16 bytes for A128GCM, 32 bytes for A256GCM). Other causes include algorithm mismatch (the tool's selected algorithm does not match the token's header), a corrupted or truncated token string, or a token that uses an unsupported algorithm variant.
When should I use JWE instead of relying solely on TLS for encryption?
TLS encrypts data in transit between two network endpoints, but it does not protect data at rest, in logs, in browser storage, or when TLS is terminated at an intermediary. JWE provides end-to-end encryption at the application layer, meaning the data remains encrypted regardless of how many network hops, proxies, load balancers, or storage systems it passes through. Use JWE when the token may be stored in browser localStorage or cookies readable by JavaScript, when tokens pass through API gateways or logging systems that should not see the payload, when regulatory requirements mandate application-layer encryption for specific data types, or when the token's recipient is different from the TLS endpoint.