JWT Authentication Explained: How JSON Web Tokens Work

📖 10 min read · Security · Try JWT Decoder →

What is JWT?

JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a compact, URL-safe JSON object. JWTs are digitally signed, which means the information they contain can be verified and trusted. They are widely used for authentication and authorization in modern web applications, REST APIs, and microservices.

A JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

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

JWT Structure: The Three Parts

1. Header

Contains the token type and signing algorithm:

{
  "alg": "HS256",
  "typ": "JWT"
}

Common algorithms: HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA-SHA256)

2. Payload (Claims)

Contains the data (claims) about the user and token:

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "email": "jane@example.com",
  "role": "admin",
  "iat": 1516239022,
  "exp": 1516242622
}

3. Signature

Created by signing the encoded header and payload with a secret key. Verifies the token has not been tampered with:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

Standard JWT Claims

Claim	Name	Description
iss	Issuer	Who issued the token (e.g., "auth.myapp.com")
sub	Subject	Who the token is about (usually user ID)
aud	Audience	Who the token is intended for
exp	Expiration	Unix timestamp when token expires
nbf	Not Before	Token is not valid before this timestamp
iat	Issued At	Unix timestamp when token was issued
jti	JWT ID	Unique identifier for the token (prevents replay)

HS256 vs RS256: Which Algorithm to Use?

HS256 (Symmetric)

Uses a single shared secret key for both signing and verification. Simple to implement. Use when the same service signs and verifies tokens.

✓ Simple, fast

✗ Secret must be shared with all verifiers

RS256 (Asymmetric)

Uses a private key to sign and a public key to verify. The private key stays secret; the public key can be shared freely. Use for microservices and third-party verification.

✓ Public key can be shared safely

✗ More complex, slightly slower

JWT Security Best Practices

Always verify the signature — Never trust a JWT without verifying its signature server-side. Decoding is not verification.
Set short expiration times — Access tokens should expire in 15–60 minutes. Use refresh tokens for longer sessions.
Use HTTPS only — JWTs transmitted over HTTP can be intercepted. Always use TLS/HTTPS.
Store tokens securely — Store in httpOnly cookies (not localStorage) to prevent XSS attacks from stealing tokens.
Validate all claims — Check exp, iss, aud, and nbf claims on every request.
Use strong secrets — For HS256, use a secret of at least 256 bits (32 random bytes). Never use weak secrets like "secret" or "password".
Implement token revocation — JWTs are stateless and cannot be invalidated before expiry. Use a token blacklist or short expiry + refresh token rotation for logout functionality.

Decode & Inspect JWTs Instantly

Paste any JWT to see its header, payload, and expiration time. All decoding happens in your browser.

JWT Decoder →