What Is a JWT?
The Three Parts of a JWT
What is JWT? A JSON Web Token (JWT, pronounced 'jot') is a compact string that carries claims, which are statements such as the user's ID, the token's expiry time or the intended audience. JWTs are defined in RFC 7519 and are often used as bearer tokens in APIs. Their payload is a JSON object, which is where the name comes from.
A JWT has three parts separated by dots. The header states the token type and the signing algorithm. The payload contains the claims. The signature is calculated from the header and payload using a secret key or a private key. Each part is encoded in base64url, so a token looks like three random-looking strings joined by dots.
Signing Is Not Encryption
The signature shows that the token was issued by a party holding the signing key and that the header and payload have not changed since. The receiver recalculates the signature, and if it differs, the token is rejected. This is what makes JWTs useful: a service can trust the claims without looking the token up in a database.
A standard JWT is signed, not encrypted. Anyone who has the token can decode it and read the payload, so it should never contain passwords or sensitive personal data. Encrypted variants exist under the name JSON Web Encryption, but they are less common in everyday APIs.
Expiry, Sessions and Revocation
JWTs usually include an expiry claim, written as exp, which marks when the token stops being valid. Short lifetimes limit the damage from a stolen token. Tokens may also carry an issuer claim and an audience claim, so a receiver can check who created the token and whether it was meant for that service.
Because the server does not store each token, a traditional server-side session can be revoked instantly by deleting it. A JWT remains valid until it expires, unless the system keeps a block list of revoked tokens. This trade-off explains why JWT sessions suit some designs better than others. Many teams use short-lived JWTs alongside refresh tokens, as described in the OAuth article.
Frequently asked questions
Is a JWT secure?
A JWT is only as secure as its signing and checking. The signature prevents tampering when the server verifies it correctly, but the payload is readable by anyone. Weak keys, or a server that accepts unexpected signing algorithms, can break the protection. Keep tokens short-lived, use HTTPS and keep secrets out of the payload.
Should I use JWTs or server sessions?
Either can work. Server sessions are easy to revoke and keep data on the server, which suits a single web application. JWTs suit systems where several services must verify a token independently, but they need careful expiry and revocation planning. Many systems use both in different parts of the architecture.