A JSON Web Token (JWT) is a compact, URL-safe token format used for securely transmitting information between parties. It consists of three Base64URL-encoded parts separated by dots: a header (algorithm and type), a payload (claims/data), and a signature (verification). JWTs are widely used for authentication and authorization in web applications and APIs.

Is it safe to decode a JWT on the client side?

Yes, decoding (reading) a JWT payload is safe — the payload is only Base64URL encoded, not encrypted, so the data is already visible to anyone with the token. However, verifying the signature should be done server-side using the secret key or public key. Never trust client-side JWT verification for security decisions.

What is the difference between HS256 and RS256?

HS256 (HMAC-SHA256) uses a shared secret key for both signing and verification — both parties must know the same secret. RS256 (RSA-SHA256) uses asymmetric cryptography — a private key signs the token and a public key verifies it. RS256 is preferred for distributed systems where multiple services need to verify tokens without sharing secrets.

How long should a JWT be valid?

Access tokens should be short-lived: 5-15 minutes for high-security applications, up to 1 hour for general use. Refresh tokens can last 7-30 days. Shorter expiration reduces the window of vulnerability if a token is compromised. Use refresh token rotation to maintain sessions without long-lived access tokens.

JWT Decoding and Security Guide: Understanding JSON Web Tokens

JSON Web Tokens (JWTs) have become the standard for stateless authentication in modern web applications and APIs. They enable secure, scalable user sessions without server-side storage — but their widespread use has also introduced a class of security vulnerabilities that developers must understand. This guide breaks down JWT structure, decoding, signing algorithms, and critical security practices.

February 23, 2026 14 min read Developer

JWT Structure: Three Parts, One Token

Every JWT consists of three Base64URL-encoded segments separated by dots:

xxxxx.yyyyy.zzzzz
  |      |      |
Header Payload Signature

Header

The header declares the token type and signing algorithm:

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

Payload (Claims)

The payload contains claims — statements about the user and metadata:

{
    "sub": "1234567890",
    "name": "John Doe",
    "role": "admin",
    "iat": 1709136000,
    "exp": 1709139600
}

Standard JWT Claims

Claim	Name	Purpose
`iss`	Issuer	Who created the token
`sub`	Subject	Who the token is about (user ID)
`aud`	Audience	Intended recipient service
`exp`	Expiration	Token expiry timestamp
`iat`	Issued At	Token creation timestamp
`nbf`	Not Before	Token not valid before this time
`jti`	JWT ID	Unique token identifier

Use the JWT decoder to inspect any token's header and payload instantly.

Signing Algorithms Explained

The signature ensures the token has not been tampered with. Choosing the right algorithm is a critical security decision:

Algorithm	Type	Key	Best For
HS256	Symmetric	Shared secret	Single-service apps
HS384 / HS512	Symmetric	Shared secret	Higher security needs
RS256	Asymmetric	RSA key pair	Distributed systems, microservices
ES256	Asymmetric	ECDSA key pair	Mobile, performance-critical
EdDSA	Asymmetric	Ed25519	Highest security + performance

Key Difference: With HS256, the same secret key signs and verifies tokens — every service that verifies needs the secret. With RS256/ES256, a private key signs and a public key verifies — services only need the public key, reducing secret exposure.

JWT Security Vulnerabilities

These are the most common JWT security issues that lead to breaches:

1. Algorithm Confusion Attack

An attacker changes the algorithm from RS256 to HS256 in the header, then signs the token with the public key (which is public!). If the server does not validate the expected algorithm, it may accept the token.

Prevention: Always validate the algorithm server-side. Never accept the algorithm from the token header alone.

2. None Algorithm

Setting "alg": "none" in the header creates an unsigned token. Some libraries accept this as valid, bypassing all signature verification.

Prevention: Explicitly reject the "none" algorithm. Use a library whitelist for accepted algorithms.

3. Token Not Expiring

JWTs without an exp claim last forever. A stolen token grants permanent access.

Prevention: Always include exp. Access tokens should expire in 5-60 minutes.

4. Sensitive Data in Payload

JWT payloads are Base64-encoded, not encrypted. Anyone can decode them. Never put passwords, credit card numbers, or secrets in JWT claims.

Prevention: Include only identifiers and roles. Use encrypted JWTs (JWE) for sensitive data.

JWT Best Practices Checklist

Use RS256 or ES256 for distributed systems
Set short expiration times (5-15 minutes for access tokens)
Implement refresh token rotation
Validate iss, aud, exp, and algorithm on every request
Store tokens in httpOnly, Secure cookies (not localStorage)
Never put sensitive data in the payload
Use a strong, random secret (256+ bits) for HMAC algorithms
Implement token revocation for logout
Generate strong secrets with the password generator

Developer Security Tools

Essential JWT & Security Toolkit:

JWT Decoder — Decode and inspect JWT tokens
Base64 Encoder/Decoder — Encode/decode Base64
Password Generator — Generate strong secrets
Hash Generator — Generate cryptographic hashes
JSON Formatter — Format JWT payloads
SSL Checker — Verify HTTPS configuration

Frequently Asked Questions

A JSON Web Token is a compact, URL-safe format for securely transmitting information. It has three parts: header, payload, and signature. JWTs are used for authentication and authorization in web apps and APIs.

Yes, decoding is safe — JWT payloads are only Base64 encoded, not encrypted. But signature verification must happen server-side. Never trust client-side verification for security.

HS256 uses a shared secret (both parties need it). RS256 uses public/private key pairs. Use RS256 for distributed systems and microservices; HS256 for single-service apps.

Access tokens: 5-15 minutes (high security) to 1 hour (general). Refresh tokens: 7-30 days. Shorter expiration reduces compromise risk. Use refresh token rotation for sessions.

Security Tools

Related Guides

Password Security
Security Tools Guide
JSON Guide