🔑 JWT Decoder

Decode & inspect JSON Web Tokens — header · payload · expiry · claims

JWT Token

Standard JWT Claims (RFC 7519)

issIssuer — who issued the token
subSubject — who the token refers to
audAudience — who the token is intended for
expExpiration time (Unix timestamp)
nbfNot before (Unix timestamp)
iatIssued at (Unix timestamp)
jtiJWT ID — unique identifier
algAlgorithm (header) — e.g. HS256, RS256
typType (header) — usually "JWT"

What is JWT Decoder?

JWT Decoder parses and displays the contents of a JSON Web Token (JWT). Paste a JWT string (the three-part dot-separated token) to see its decoded header, payload, and signature in a readable format. The tool shows all claims — standard ones (iss, sub, aud, exp, iat, nbf) and custom claims — with human-readable timestamps for exp and iat. Note: this tool only decodes and does not verify the signature.

A JWT (JSON Web Token) consists of three Base64URL-encoded parts separated by dots: Header.Payload.Signature. Header: contains the algorithm (alg: HS256, RS256, ES256) and token type (typ: JWT). Payload: the claims — assertions about an entity (user) and additional metadata. Signature: computed from the header, payload, and a secret or private key — used to verify the token hasn't been tampered with. Only the signature provides security; the header and payload are not encrypted (just encoded) and can be decoded by anyone.

JWT is used for: authentication (after login, server issues a JWT; client sends it in Authorization: Bearer header for subsequent requests), API authorization, information exchange between services. JWTs are stateless — the server doesn't need to store session state. This is both an advantage (scalable) and disadvantage (can't revoke individual tokens before they expire without a blocklist). JWT best practices: short expiration times (15-60 minutes), use refresh tokens for long sessions, use RS256 or ES256 (asymmetric) instead of HS256 for multi-service architectures.

How to Use

  1. Paste a JWT token into the input field (the full three-part string).
  2. The header, payload, and signature are decoded and displayed in JSON format.
  3. Hover over 'exp', 'iat', and 'nbf' timestamps to see human-readable dates.
  4. Check the 'Expired?' indicator to see if the token's exp claim has passed.
  5. See the algorithm used in the header — important for security considerations.

Examples

Decode a JWT

Result: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIiwiZXhwIjoxNzg4ODAwMDAwfQ.xxx → {sub:'user123', exp:'2026-08-07T...' }

Check expiration

Result: exp: 1788800000 → 2026-08-07T04:26:40Z → Status: ✓ Not expired

Identify algorithm

Result: Header: {alg: 'RS256', typ: 'JWT'} → RSA with SHA-256 → asymmetric signature

Frequently Asked Questions

What is the difference between HS256, RS256, and ES256 in JWT?

These are JWT signature algorithms: HS256 (HMAC with SHA-256): symmetric — uses the same secret key to sign and verify. Fast, simple. Risk: any service that can verify tokens can also create them. RS256 (RSA with SHA-256): asymmetric — private key signs, public key verifies. The public key can be shared freely; only the auth server (with the private key) can issue tokens. Standard for multi-service architectures. Slower than HS256. ES256 (ECDSA with SHA-256): asymmetric like RS256 but using elliptic curve cryptography — smaller key sizes, faster than RSA, equally secure. Use RS256 or ES256 for production.

Is JWT encrypted? Can anyone read my token?

No — JWT is NOT encrypted by default. The header and payload are Base64URL-encoded, not encrypted. Anyone who has the JWT can decode and read the payload. This is why you should never put sensitive data (passwords, SSNs, credit card numbers) in JWT claims. JWE (JSON Web Encryption) is the standard for encrypted JWTs, but it's rarely used in practice. Treat JWTs like session tokens — protect them in transit (HTTPS only), store securely (httpOnly cookies, not localStorage — localStorage is accessible to JavaScript), and use short expiration times.

What is the difference between access tokens and refresh tokens?

Access token: short-lived JWT (typically 15-60 minutes). Sent with every API request in Authorization: Bearer header. Stateless — server validates by verifying signature, no database lookup needed. Refresh token: long-lived opaque token (days to months). Stored securely (httpOnly cookie). Used only to obtain new access tokens when they expire. The auth server stores refresh tokens — this allows revocation. Workflow: login → server issues access token + refresh token → access token expires → client sends refresh token to /token endpoint → server issues new access token (and optionally new refresh token).

Where should I store a JWT on the client?

Options: localStorage: easy to use, but vulnerable to XSS — any JavaScript on the page can read it. If you store JWTs in localStorage, a single XSS vulnerability compromises all tokens. httpOnly cookie: not accessible to JavaScript — immune to XSS. Sent automatically with requests (CSRF risk — mitigate with SameSite=Strict or a CSRF token). sessionStorage: cleared when tab closes, still XSS-vulnerable. Recommendation: httpOnly, Secure, SameSite=Strict cookies for refresh tokens. Memory (JS variable) for access tokens — cleared on page reload, not persisted. This is the approach used by Auth0 and the oauth-agent-node-express pattern.

How do I validate a JWT in my API?

Validation steps: (1) Split by dots — must have exactly 3 parts. (2) Base64URL-decode header and payload. (3) Verify the signature using the algorithm from the header and the secret/public key. (4) Check exp claim — reject if current time > exp. (5) Check iss (issuer) and aud (audience) if present. Never validate with alg: none — reject tokens with this algorithm. Libraries: Node.js: jsonwebtoken, jose. Python: python-jose, PyJWT. Go: golang-jwt/jwt. Java: java-jwt (Auth0). Don't implement JWT verification yourself — use a well-tested library.

Related Tools