What is a JWT token?

What JWT means

JWT stands for JSON Web Token. It is a compact token format used to pass claims between systems, most often in login sessions, API authorization, single sign-on, and service-to-service authentication.

A JWT is common because it is portable: it fits inside an HTTP Authorization: Bearer ... header, can be read by different services, and can be signed so the receiver can detect tampering.

Use the JWT Decoder to paste a token and inspect its parts locally.

The three parts of a JWT

A compact JWT usually looks like this:

header.payload.signature

Each part is Base64URL encoded.

Part	What it contains	Example fields
Header	Token metadata	alg, typ, kid
Payload	Claims about the subject/session	sub, iss, aud, exp, iat, scope
Signature	Cryptographic proof over header and payload	HMAC, RSA, or ECDSA signature

The header and payload are encoded, not encrypted. Anyone who gets the token can decode those two sections. Do not put passwords, API keys, private data, refresh tokens, or payment data in the payload.

Common JWT claims

JWT claims are name-value pairs inside the payload.

Claim	Meaning
sub	Subject, usually the user or service identity
iss	Issuer, the authority that created the token
aud	Audience, the service that should accept the token
exp	Expiration time
iat	Issued-at time
nbf	Not-before time
scope or roles	Permissions or roles

The exp claim is especially important. RFC 7519 says a token must not be accepted on or after its expiration time. In practice, every authentication service should enforce expiration and reject expired tokens.

Decoding is not verification

Decoding a JWT only makes the JSON visible. It does not prove the token is valid.

To trust a JWT, the receiving service should:

• Verify the signature with the expected key.
• Enforce the expected algorithm instead of trusting whatever alg says.
• Validate iss and aud.
• Enforce exp, and usually check nbf and iat.
• Reject tokens with missing or unexpected critical claims.

The JWT Security Checker highlights these issues and includes a local signature verification option.

Why JWTs are useful

JWTs are useful when a system needs a compact, signed claim set. For example, an API gateway can verify a token and pass trusted identity information to backend services. A mobile app can send an access token with each request. A single sign-on provider can issue tokens to several applications.

The benefit is convenience and portability. The risk is that a bad implementation can make tokens too powerful, too long-lived, or too easy to misuse.

Safe JWT design checklist

• Use short-lived access tokens.
• Keep refresh tokens separate and better protected.
• Do not store sensitive data in the payload.
• Do not accept alg: none for authentication.
• Pin the expected signing algorithm on the server.
• Validate issuer and audience.
• Rotate signing keys carefully.
• Prefer HTTPS-only transport everywhere.
• Think carefully before storing tokens in localStorage.

FAQ

Is a JWT encrypted?

Usually no. A normal signed JWT is readable. It protects integrity, not confidentiality. If you need confidentiality, use an encryption design such as JWE or keep sensitive data out of the token.

Can I change the JWT payload?

You can edit the payload text, but a correctly implemented server will reject the token because the signature no longer matches.

Should JWTs be stored in localStorage?

It depends on the application threat model, but localStorage is exposed to JavaScript. If an XSS bug exists, an attacker may read tokens from it. Many browser apps prefer short-lived access tokens and server-set HttpOnly, Secure, SameSite cookies where the architecture allows it.

References

• RFC 7519: JSON Web Token
• OWASP JSON Web Token Cheat Sheet
• OWASP Testing JSON Web Tokens