Signed JWTs protect integrity; they do not make claims confidential

A signed or MAC-protected JWT can let a recipient verify integrity under the appropriate key. Its ordinary encoded claims are not thereby confidential. An encrypted JWT uses a different protection mechanism. Base64url representation by itself supplies neither secrecy nor trust.

Illustrative example: a readable token carries a user identifier and an internal note. Adding a valid signature prevents undetected modification by someone lacking the relevant signing capability; it does not hide the note from someone holding the token. Avoid including unnecessary sensitive material merely because a token is signed.

At validation time, use an appropriate library and configured algorithm policy, validate the trusted issuer and intended audience, and apply the token type's required time and application checks. Accepting parseable JSON or a verified signature alone is not the complete decision.

Choose encryption when the protocol and threat model require confidential claims, or prefer an opaque reference where that better fits the architecture. Encryption does not remove the need to validate the token and authorize the action.

Limit: not every JWT profile uses the same required claims or protections. Follow the governing profile and its current security guidance; this comparison is not a complete token-validation specification.