What is a JWT? JSON Web Tokens Explained

Home Glossary What is a JWT? JSON Web Tokens Explained

A JWT (JSON Web Token, often pronounced "jot") is a compact, digitally signed token for securely passing information between systems. A JWT contains claims, such as who the user is, which rights they have and when the token expires, and a signature that lets the receiving system verify that the token was issued by a trusted party and has not been changed. JWTs are standardised in RFC 7519 and widely used for API authentication, single sign-on and as ID tokens in OAuth and OpenID Connect.

What does a JWT look like?

A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature.

  • Header: the token type and the signing algorithm, such as HS256 or RS256.
  • Payload: the claims. Standard claims include iss (issuer), sub (subject, usually the user ID), aud (audience), exp (expiry time) and iat (issued at), supplemented with custom claims such as roles.
  • Signature: calculated over the header and payload with a secret key (HMAC) or a private key (RSA or ECDSA).

How is a JWT used?

  1. The user logs in, and the authentication server issues a signed JWT.
  2. The client sends the token with every API request, usually in the header Authorization: Bearer <token>.
  3. The API verifies the signature, the expiry time, the issuer and the audience, and reads the user and rights from the claims, without a database lookup.

Because the API can check the token itself, JWTs work well for stateless APIs and microservices: every service can verify the token with the public key, which the issuer often publishes as a JWKS endpoint so keys can be rotated.

Security pitfalls

  • Signed is not encrypted: anyone can decode and read the payload. Never put passwords or sensitive personal data in it. For encrypted tokens there is JWE.
  • Always validate fully: check the signature with an explicitly allowed algorithm (never none), and check exp, iss and aud.
  • Revocation is hard: a JWT stays valid until it expires. Keep access tokens short-lived and use refresh tokens, or keep a blocklist for emergencies.
  • Storage in the browser: tokens in localStorage can be stolen through XSS; HttpOnly cookies are often safer for web apps.

See our API development, REST API development and what is authentication.

Frequently Asked Questions about JWT

What is the difference between a JWT and a session cookie?

With a session, the server stores the login state and the cookie only contains a session ID. A JWT contains the information itself, so the server doesn't need to store anything. Sessions are easier to revoke; JWTs scale more easily across services.

Is a JWT secure?

A JWT is secure if it is signed with a strong key, fully validated, short-lived, sent only over HTTPS and contains no sensitive data. Most JWT vulnerabilities come from incomplete validation.

What is the difference between HS256 and RS256?

HS256 uses one shared secret for signing and verifying, so every verifier can also create tokens. RS256 uses a private key to sign and a public key to verify, which is safer when several services need to verify tokens.

How long should a JWT be valid?

Access tokens typically for minutes up to an hour. Longer sessions are handled with refresh tokens, which can be revoked.