A random content encryption key (CEK) encrypts the payload with an AEAD such as A256GCM or A128CBC-HS256 (enc); the CEK reaches the recipient through the key management algorithm (alg): RSA-OAEP-256, ECDH-ES (direct agreement, empty encrypted-key part) or ECDH-ES+A256KW, A256KW with a shared key, or dir for a pre-shared CEK. The protected header is the AEAD's associated data, so it cannot be altered.
A JWE gives confidentiality toward its recipient but no sender authentication with ECDH-ES or RSA-OAEP: anyone with the public key can create one. Nested JWTs sign first and then encrypt the signed JWT, with cty set to JWT. Known pitfalls are invalid-curve points in ECDH-ES (validate the epk), PBES2 with huge iteration counts as a denial-of-service vector, and the RSA1_5 padding oracle; RFC 8725 lists the mitigations.
Most APIs never need JWE because TLS already protects the channel; it is useful for tokens that pass through untrusted intermediaries or are stored by clients. The JWE inspector shows header and structure without decrypting.