What a JWT is made of
A JSON Web Token (RFC 7519) is three base64url-encoded segments joined by dots: header.payload.signature. The header is a small JSON object naming the signing algorithm and token type, typically {"alg":"HS256","typ":"JWT"}. The payload is another JSON object holding the claims - who the token is about, who issued it, when it expires, and whatever application data the issuer chose to include. The signature is computed over the first two segments and proves that nobody altered them.
base64url is ordinary Base64 with - in place of +, _ in place of /, and the trailing = padding dropped so the token is safe in URLs and HTTP headers. That is all the encoding there is. A JWT is not encrypted. Anyone who copies a token out of a browser's local storage or a log file can read every claim in it, which is why user email addresses are common in tokens and passwords, card numbers and internal secrets must never be.
Registered claims and expiry
Seven claim names are reserved by the spec. iss is the issuer, sub the subject (usually a user ID), aud the intended audience, jti a unique token ID used for revocation lists, and three are timestamps: iat (issued at), nbf (not before) and exp (expires). All three are Unix seconds, not milliseconds - a common bug is passing Date.now() straight into exp, which produces a token that expires in the year 52,000. This page converts each timestamp to your local time and shows how far away it is.
Expiry matters because a JWT is a bearer token: whoever holds it is treated as the user, and there is no central session to delete. Typical lifetimes are 5 to 15 minutes for an access token, paired with a longer-lived refresh token that can be revoked server-side. Verifiers normally allow a small clock skew, often 60 seconds, so a token that expired 10 seconds ago may still be accepted. If the token here shows as expired but your API accepts it, check the server clock and the skew setting.
Decoding is not verifying
This tool reads a token; it does not check the signature, and it does not ask for your secret or your public key. Verification requires recomputing the HMAC with the shared secret (for HS256) or checking an RSA or ECDSA signature against the issuer's public key (for RS256, ES256 and friends), and it belongs on your server, not on a web page. Treat any site that asks you to paste a production signing secret as a credential leak waiting to happen.
Two classic vulnerabilities are worth knowing when you look at the header. The alg: none attack strips the signature and sets the algorithm to none; a verifier that trusts the header will accept it, so libraries must be configured with an allowed algorithm list. The RS256 to HS256 confusion attack re-signs a token using the public key as an HMAC secret, which works against implementations that pick the algorithm from the token instead of from configuration. Always pin the expected algorithm, always check iss and aud, and reject anything that arrives without an exp.