JSON Web Tokens (JWT) are compact, URL-safe tokens used for securely transmitting information between parties. They're commonly used for authentication and information exchange in modern web applications and APIs.

JWT Structure

Header.Payload.Signature

Each part is Base64 URL encoded and separated by dots (.)

1. Header

Contains token type (JWT) and signing algorithm (HS256, RS256, etc.)

2. Payload

Contains claims (user data, permissions, expiration, etc.)

3. Signature

Verifies token integrity using secret key or public/private key pair

Common Use Cases

✓Authentication: Verify user identity after login without sessions
✓Authorization: Control access to API endpoints and resources
✓Single Sign-On (SSO): Share authentication across multiple services
✓API Security: Secure REST APIs with stateless authentication
✓Information Exchange: Securely transmit verified data between parties
✓OAuth 2.0: Used as access and refresh tokens in OAuth flows

Standard Claims (Registered)

Claim	Full Name	Description
iss	Issuer	Who created and signed the token
sub	Subject	User ID or subject identifier
aud	Audience	Who the token is intended for
exp	Expiration Time	When the token expires (Unix timestamp)
iat	Issued At	When the token was created (Unix timestamp)
nbf	Not Before	Token not valid before this time
jti	JWT ID	Unique identifier for the token

Signing Algorithms

HMAC (Symmetric)

HS256: HMAC with SHA-256 (most common)
HS384: HMAC with SHA-384
HS512: HMAC with SHA-512

Uses shared secret key. Same key signs and verifies.

RSA/ECDSA (Asymmetric)

RS256: RSA with SHA-256
ES256: ECDSA with SHA-256
PS256: RSA-PSS with SHA-256

Uses key pair. Private key signs, public key verifies.

Security Best Practices

✓ Do's

• Always verify signatures on the server
• Use HTTPS to prevent token interception
• Set short expiration times (exp claim)
• Store tokens securely (httpOnly cookies preferred)
• Include audience (aud) and issuer (iss) claims
• Use strong algorithms (RS256, ES256 for production)
• Implement token refresh mechanisms

✗ Don'ts

• Don't store sensitive data in payload (it's not encrypted!)
• Don't use 'none' algorithm in production
• Don't share secret keys or tokens publicly
• Don't skip signature verification
• Don't store tokens in localStorage (XSS vulnerable)
• Don't use weak secrets for HMAC algorithms
• Don't trust decoded tokens without verification

Frequently Asked Questions

Are JWT tokens encrypted?

No, standard JWTs are signed but not encrypted. The payload is Base64 encoded and easily decoded. Anyone can read the contents. For encryption, use JWE (JSON Web Encryption) instead.

Can I decode a JWT without the secret?

Yes! Decoding only reads the Base64 encoded content. The secret is needed for verification(checking if the signature is valid). This tool decodes but doesn't verify.

How long should JWT tokens be valid?

Short-lived access tokens (5-15 minutes) with long-lived refresh tokens (days/weeks) is recommended. Balance security (shorter is safer) with user experience (longer requires fewer refreshes).

Should I use JWT for sessions?

JWT works for stateless authentication but has tradeoffs: can't revoke tokens easily, larger than session IDs, and all data is sent with each request. Consider your use case: JWTs excel for APIs and microservices, sessions work well for traditional web apps.

What's the difference between HS256 and RS256?

HS256 uses a shared secret (symmetric) - same key for signing and verification. RS256 uses RSA key pairs (asymmetric) - private key signs, public key verifies. Use RS256 when multiple services need to verify but not create tokens.

Can I modify a JWT token?

You can modify the payload, but the signature will no longer be valid. Any verification will fail. This is by design - JWT's signature ensures integrity. To legitimately change data, you must re-sign with the secret key.

JWT Decoder

Security Notice

About JSON Web Tokens (JWT)