jwt-decode
semver
>=3.0.0 <5.0.0postconditions2functions1last verified2026-04-16coverage score100%Postconditions — what we check
- jwtDecode · invalid-tokenerrorWhentoken is not a string, missing dot separators, has invalid base64 encoding, or has invalid JSON after decodingThrows
InvalidTokenErrorRequired handlingCaller MUST wrap jwtDecode() in a try-catch block. JWT tokens received from auth systems can be malformed, truncated, expired, or tampered with. Any malformed token throws InvalidTokenError synchronously. Missing try-catch causes an unhandled exception that crashes the current request or renders the auth flow broken.costhighin prodimmediate exceptionusers seeauthentication failurevisibilityvisible - jwtDecode · no-signature-validationwarningWhencaller uses decoded payload fields (sub, role, exp, permissions, etc.) to make authorization or authentication decisions without independent server-side JWT verification. jwtDecode() performs ONLY base64url decoding — it does not verify the HMAC or RSA signature, does not check exp expiry, does not validate iss or aud claims, and accepts any structurally valid JWT regardless of whether it was signed by a trusted key.Throws
no exception — returns decoded payload from forged or tampered tokens silentlyRequired handlingCallers MUST NOT rely solely on jwtDecode() for security-critical decisions. Any claim read from jwtDecode() output (sub, role, exp, permissions) MUST be independently validated server-side using a signature-verifying library such as jsonwebtoken.verify(), jose.jwtVerify(), or equivalent. Use jwtDecode() only for non-security purposes such as reading display metadata (e.g., user display name) or logging, never for access control. If exp is read to check token freshness, the actual token must still be server-validated on each request.costcriticalin prodsilent failureusers seesecurity breachvisibilitysilent
Sources
Every postcondition cites at least one of these. Numbered to match the footnotes above.
Need a different package?
Request a profile