Does decoding a JWT verify it?

No. Decoding only reads the header and payload. Verification requires checking the signature, issuer, audience and expiry on the server.

What is the difference between JWS and JWE?

A JWS is signed and readable. A JWE is encrypted and has five parts; its payload cannot be read without the decryption key.

Where should I verify a JWT?

On the server, using the correct key and a trusted library. Never rely on client-side decoding for access control.

JWT Structure and Claims Explained

A practical explanation of JWT structure, common claims and the difference between decoding and verifying.

What a JWT Is

A JSON Web Token (JWT) is a compact way to represent claims between two parties. It is commonly used for authentication and authorization: a server issues a token after login, the client sends it with later requests, and the server verifies it before granting access. A signed JWT is readable by anyone who has it; it is not encrypted by default.

The Three Parts of a JWS

A signed JWT (JWS) has three dot-separated parts:

header.payload.signature

Header: JSON with the signing algorithm and token type, for example {"alg":"HS256","typ":"JWT"}.
Payload: JSON with claims about the subject, issuer, audience and time.
Signature: a cryptographic value over the encoded header and payload.

The header and payload are Base64URL-encoded. That is an encoding, not encryption. The signature is what allows a server to detect modification and verify who issued the token.

Common Claims

iss — issuer.
sub — subject, usually the user or entity.
aud — intended audience.
exp — expiration time as a Unix timestamp.
nbf — earliest time the token can be used.
iat — issued-at time.
jti — unique token identifier, useful for revocation.

Claims are not automatically enforced by the token format. The server must validate the ones that matter for its security model.

Decoding vs Verification

Decoding reads the header and payload. It does not check the signature, issuer, audience or expiry. A token can be decoded by anyone who has it, including an attacker. Verification is a server-side operation that uses the correct key and a trusted library to check the signature and claims before accepting the token.

This is why a decoder is useful for debugging and learning, but dangerous as an access-control mechanism. Never trust decoded data until the server has verified the token.

JWS vs JWE

A JWS is signed and readable. A JWE is encrypted and has five parts. A JWE payload cannot be read without the decryption key, so a decoder can show the header but not the claims. If you paste a five-part token, expect the payload to be marked as encrypted.

Common Decoding Errors

Missing or extra parts

A JWS must have exactly three parts. Extra dots usually mean the token is malformed or is a JWE. Copy the token exactly as issued.

Invalid Base64URL

JWT segments use Base64URL, which replaces + with - and / with _. Standard Base64 characters or truncated strings can cause errors.

Invalid payload JSON

The payload must be valid JSON. If decoding fails after Base64URL decoding, inspect the raw segment for corruption.

Expired tokens

An expired token can still be decoded. Expiry affects whether a server should accept it, not whether the payload is readable.

Signing Algorithms

HS256 uses a shared secret for signing and verification, which is simple but requires every verifier to hold the secret. RS256 and ES256 use a private key to sign and a public key to verify, which is useful when many services need to verify tokens without being able to mint them. The algorithm is named in the header, but a server must not blindly trust it: choose an allowed algorithm, reject none, and use the correct key type. Mixing up symmetric and asymmetric keys is a serious security bug.

Token Storage

Where you store a token affects the threat model. Browser storage accessible to JavaScript is vulnerable to cross-site scripting; HttpOnly cookies are not readable by JavaScript but require CSRF protection. Short-lived tokens and secure refresh flows reduce the impact of theft. Avoid putting tokens in URLs, logs or analytics events, and clear them on logout.

Security Checklist

Verify tokens on the server, never only in the browser.
Validate the algorithm, issuer, audience and expiry.
Use short-lived access tokens and refresh tokens where appropriate.
Keep signing keys secret and rotate them when needed.
Do not store passwords, private keys or sensitive personal data in the payload.
Use HTTPS so tokens are not exposed in transit.

A Practical Workflow

Paste the token into the JWT Decoder.
Inspect the header, payload and time claims.
Check whether the token is expired, but remember that expiry is not verification.
Verify the signature and claims on your server before trusting the data.

To inspect individual segments, use the Base64 Encoder / Decoder. To convert exp and iat values, use the Unix Timestamp Converter.