Encoding & Transport
JWS vs JWE for Readable and Encrypted JWTs
Understand the difference between signed and encrypted JOSE objects so you know when decode is possible and when it is not.
Developers often say “JWT” when they mean one of two different JOSE objects. That shorthand is harmless until someone pastes a five-part token into a decoder and expects the payload to appear.
Signed JWS payloads can usually be decoded without a key. Encrypted JWE payloads require decryption. Verification and decryption are separate operations.
In brief
What it is: JWS protects integrity and authenticity with a signature or MAC, while JWE protects confidentiality by encrypting content.
Why it matters: If you misidentify the object, you will reach for the wrong tool and misread normal behavior as a failure.
Worth knowing: Decode a JWS to inspect its claims, verify it before trusting them, and decrypt a JWE with the intended recipient key to read its payload.
Count the segments first
Compact JWS commonly appears as three Base64URL segments: header, payload, signature. Compact JWE commonly appears as five: protected header, encrypted key, IV, ciphertext, authentication tag. If you count first, you avoid a surprising number of wrong turns.
This is a good example of pyramid-principle debugging. Start with the highest-level distinction that splits the problem in two. Only after you know whether the object is signed or encrypted does it make sense to talk about keys, claims, or algorithms.
What you can inspect without the key
With JWS, the header and payload are Base64URL encoded, not secret by default. You can inspect them. You still have to verify the signature separately. With JWE, only the protected header is directly visible. The payload stays encrypted until the correct decryption path is available.
That difference matters operationally. A decode tool should never imply that an encrypted payload is “broken” because it stays unreadable. Readability is the wrong expectation in the first place.
- JWS: inspectable structure, verification still required.
- JWE: visible header, unreadable payload until decryption.
- JWT is a family label in conversation, not a promise that the object is readable.
Where real incidents go sideways
Anyone who sees a JWS can usually decode its payload and must still verify the signature. A five-part JWE keeps the payload encrypted until decryption.
Label the token first, inspect the fields that should be visible, verify JWS objects, and decrypt JWE objects.
See it in a small example
Notice: The segment count is not the whole story, but it is the fastest first sort. Three segments usually means signed content. Five usually means encrypted content.
JWS compact: header.payload.signature
JWE compact: protectedHeader.encryptedKey.iv.ciphertext.tag
What to verify
- Count segments before trying to decode claims.
- If the object has five parts, stop expecting the payload to be readable without a key.
- Treat Base64URL readability as a way to inspect claims, then verify the signature and validation rules before trusting them.
Common questions
Can a JWS still contain sensitive information?
Yes. Signed does not mean encrypted, so sensitive claims should be treated carefully.
Can I verify a JWE the same way I verify a JWS?
JWE is about decryption and authentication of encrypted content, not a detached signature workflow.
