Encoding and security guides
JWT containers: distinguish JWS from JWE
Recognize compact serialization shapes and avoid treating encrypted JWT data as a decodable three-part token.
Count segments as a first clue
A compact JWS has three segments; compact JWE has five. JWT claims can be carried in signed or encrypted structures.
Segment count is a diagnostic clue, not a complete validity check. Do not change the number of dots to force a decoder to accept a token.
JWS: protected.payload.signature
JWE: protected.encryptedKey.iv.ciphertext.tagDecode only what is readable
A JWE protected header is encoded JSON, but its ciphertext is encrypted bytes rather than a readable JSON claim set.
Base64URL decoding ciphertext cannot reveal the claims. Decryption needs the intended algorithms, keys and authenticated tag checks.
Understand empty segments
Some JWE key-management modes can produce an empty encrypted-key segment. That still leaves the five-segment compact structure.
Do not remove empty fields when splitting or reconstructing a token. A generic filter that drops empty strings can corrupt the format.
Use the supported tool scope
The site JWT Decoder inspects ordinary three-part tokens; its HS256 verifier does not implement JWE decryption.
For nested signed-and-encrypted tokens, use a JOSE library implementing the agreed processing order and verify each layer before trusting claims.