JWT Decoder

JWT Decoder

Decode and inspect JSON Web Tokens. View header, payload, and verify expiry. Browser-side, never sent.

What is JWT?

JSON Web Token (JWT) is a compact, URL-safe way to represent claims securely between two parties. Specified in RFC 7519, JWTs are the standard for authentication in modern web apps and APIs – users log in once, get a JWT, then send it with each request to prove identity. A JWT has 3 parts separated by dots: header (algorithm and type), payload (claims like user ID, expiry), and signature (cryptographic verification). The first two parts are base64-encoded JSON – readable by anyone! Only the signature provides security. This decoder shows you the header and payload without verifying the signature – useful for debugging, learning, and inspecting tokens. NEVER store sensitive data in JWT payload – it’s not encrypted.

How to use this tool

  1. Paste JWT token — Token format: three base64 parts separated by dots (xxx.yyy.zzz). Get from browser localStorage, HTTP headers, or cookies.
  2. View decoded sections — Header (algorithm), Payload (user data, claims), Signature (raw base64 – not decoded, requires secret key).
  3. Check status info — Tool shows: issuer (iss), subject (sub), expiry (exp), algorithm (alg). If exp is in past, marked EXPIRED.

JWT structure

Format: header.payload.signature

Each section is base64url-encoded.

Header (decoded):

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

Payload (decoded):

{
  "sub": "user123",
  "name": "Vidhaata",
  "iat": 1716700800,
  "exp": 1716787200
}

Standard claims:

  • iss – issuer (who created token)
  • sub – subject (who token is about)
  • aud – audience (intended recipient)
  • exp – expiration time (Unix timestamp)
  • nbf – not before (valid from)
  • iat – issued at time
  • jti – JWT ID (unique identifier)

Examples

Typical JWT use:

  1. User logs in with username/password
  2. Server creates JWT with user ID and signs with secret
  3. Client stores JWT in localStorage or cookie
  4. Every API request includes: Authorization: Bearer eyJhbGc...
  5. Server verifies signature with same secret, grants/denies access

Token lifetime patterns:

  • Short-lived (15 min – 1 hour): Use refresh tokens for renewal
  • Medium (1 day): Balance security and UX
  • Long-lived (30+ days): Rare – high security risk if stolen

Tips & best practices

  • JWT payload is BASE64 ENCODED, NOT ENCRYPTED – anyone can read it
  • Never store passwords, credit cards, or secrets in JWT payload
  • Always use HTTPS – JWTs in clear text can be stolen via network sniffing
  • Implement refresh tokens – short-lived access JWTs + long-lived refresh tokens
  • Use HS256 for symmetric (single server). Use RS256 for asymmetric (microservices)
  • Verify signature on EVERY request server-side – this is your only security
  • Store JWT in httpOnly cookie (more secure) vs localStorage (XSS vulnerable)
  • Set short exp time (15-60 min) – reduces blast radius if token leaked

Limitations & notes

This tool only DECODES JWTs – doesn’t verify signature. Verification requires the server’s secret key (HS256) or public key (RS256). For complete security validation, use server-side libraries. JWTs from production environments may contain sensitive personal data – decode carefully and never log decoded JWTs.

Frequently Asked Questions

Is JWT encrypted?

NO. JWT payload is base64-encoded JSON – completely readable by anyone with the token. The signature provides INTEGRITY (token wasn’t tampered with), not CONFIDENTIALITY. For encryption, use JWE (JSON Web Encryption) – different specification.

Can I trust the data in a JWT?

If the signature is verified server-side with the correct secret, yes – the data is unchanged from when it was issued. Without verification, no – anyone can create a fake JWT. Always verify server-side.

Why do JWTs have 3 parts?

Header (algorithm info), Payload (claims/data), Signature (verification). Each base64url-encoded and separated by dots. Header and payload are readable. Signature is computed from header+payload+secret – changes if anything is tampered with.

How do I refresh an expired JWT?

Use refresh tokens. Pattern: short access token (15 min) + long refresh token (30 days). When access token expires, exchange refresh token for new access token. If refresh token expires too, re-authenticate. Refresh tokens stored separately, often httpOnly cookie.

Where should I store JWT in the browser?

Two options: localStorage (simple but vulnerable to XSS) or httpOnly cookie (secure from XSS but needs CSRF protection). For most apps, httpOnly cookies with SameSite=Strict are recommended for security.

What’s the difference between HS256 and RS256?

HS256 (HMAC-SHA256): symmetric – same secret signs and verifies. Use when one server creates and verifies. RS256 (RSA-SHA256): asymmetric – private key signs, public key verifies. Use in microservices where multiple services need to verify.

Can JWTs be revoked?

Not natively. JWTs are self-contained – servers don’t need a database to verify. To revoke, you need a blacklist (defeats the stateless purpose) or use short expiry + refresh tokens (you revoke the refresh token, access tokens expire quickly).

Related tools

Hash Generator · Password Generator · Base64 Encoder

Copied to clipboard