Want to learn more?
Learn about JWT authentication, token structure, and security best practices.
Read the guideDecode JWT Tokens Online - Free JWT Decoder Tool
Use this free online JWT decoder to instantly decode and analyze JSON Web Tokens. Simply paste your JWT token to view the decoded header, payload, and signature. Our JWT decoder tool runs entirely in your browser - your tokens are never sent to any server.
What You Can Do:
- • Decode JWT access tokens and ID tokens
- • View token header (algorithm, type)
- • Inspect payload claims (sub, exp, iat, iss, aud)
- • Check token expiration status
- • Analyze custom claims and scopes
Supported Token Types:
- • HS256, HS384, HS512 (HMAC)
- • RS256, RS384, RS512 (RSA)
- • ES256, ES384, ES512 (ECDSA)
- • OAuth 2.0 access tokens
- • OpenID Connect ID tokens
JWT Security Concerns?
Our DevSecOps team audits authentication implementations, token handling, and API security.
Decode and Inspect JWT Tokens
JSON Web Tokens (JWTs) are used for authentication and authorization in modern web applications. This tool decodes JWTs to show their header, payload, and signature.
JWT Structure
- Header: Algorithm and token type
- Payload: Claims (user data, expiration, issuer)
- Signature: Cryptographic verification
What You Can Inspect
- Token expiration and issue times
- User claims and permissions
- Signing algorithm (HS256, RS256, etc.)
- Signature validity (with your secret key)
How JWT Authentication Works
Understanding JSON Web Tokens
JSON Web Tokens (JWTs) are a compact, URL-safe way to represent claims between two parties. They're widely used for authentication and authorization in modern web applications.
JWT Structure
Every JWT consists of three parts separated by dots (.):
- Header - Contains the token type (
JWT) and the signing algorithm (e.g.,HS256,RS256) - Payload - Contains the claims (data) such as user ID, expiration time, and permissions
- Signature - Verifies the token hasn't been tampered with
xxxxx.yyyyy.zzzzz
Header.Payload.Signature
Common JWT Claims
JWTs use standardized claims to convey information:
| Claim | Full Name | Purpose |
|---|---|---|
iss | Issuer | Who created the token |
sub | Subject | Who the token refers to (usually user ID) |
exp | Expiration | When the token expires (Unix timestamp) |
iat | Issued At | When the token was created |
aud | Audience | Intended recipient of the token |
nbf | Not Before | Token is not valid before this time |
JWT Security Best Practices
- Always verify the signature before trusting token claims
- Check the expiration (
exp) to prevent replay attacks - Use HTTPS only - JWTs should never be transmitted over unencrypted connections
- Keep tokens short-lived - Access tokens should expire in minutes, not days
- Store securely - Prefer HttpOnly cookies over localStorage for web apps
- Never store sensitive data in the payload - JWTs are encoded, not encrypted
When to Use JWTs
JWTs work best for:
- Stateless authentication - No server-side session storage needed
- API authorization - Pass user context between microservices
- Single Sign-On (SSO) - Share authentication across multiple domains
Avoid JWTs for:
- Session management requiring instant logout capability
- Storing large amounts of user data (size limits apply)
References & Citations
- Internet Engineering Task Force (IETF). (2015). JSON Web Token (JWT) - RFC 7519. Retrieved from https://datatracker.ietf.org/doc/html/rfc7519 (accessed January 2025)
- Tim McLean. (2015). Critical vulnerabilities in JSON Web Token libraries. Retrieved from https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ (accessed January 2025)
Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.
Key Security Terms
Understand the essential concepts behind this tool
OAuth (Open Authorization)
An open standard for delegated access authorization that allows applications to access user resources without exposing credentials.
API (Application Programming Interface)
A set of rules and protocols that allows different software applications to communicate and exchange data.
Frequently Asked Questions
Common questions about the JWT Decoder
JSON Web Token (JWT) is a compact, URL-safe token format for securely transmitting information between parties. Contains three Base64-encoded parts separated by dots: header (algorithm + type), payload (claims/data), signature (verification). Used in OAuth 2.0, API authentication, single sign-on (SSO). Self-contained - no server-side session storage needed. Stateless authentication standard (RFC 7519).
JWT has three parts: header.payload.signature. Decode each part separately using Base64 decoding. Header and payload are JSON objects. Signature is cryptographic verification. Example: eyJhbGc... (header) . eyJzdWI... (payload) . SflKxwRJ... (signature). Our tool automatically splits and decodes all parts. Reveals claims like user ID, expiration, issuer. Does not verify signature.
Decoding is safe - JWTs are not encrypted by default, only Base64-encoded (publicly readable). Anyone can decode without the secret key. Decoding reveals payload data but cannot modify token. Never store sensitive data in JWT payload (visible to anyone). Use HTTPS to prevent interception. Signature verification requires secret key - use server-side validation libraries.
Claims are key-value pairs in JWT payload. Standard claims: iss (issuer), sub (subject/user ID), aud (audience), exp (expiration timestamp), nbf (not before), iat (issued at), jti (JWT ID). Custom claims: roles, permissions, email. Claims are not encrypted - visible to anyone. Keep payload small (<8KB). Verify claims server-side. Expired tokens should be rejected.
Secure: RS256 (RSA + SHA-256, asymmetric), ES256 (ECDSA + SHA-256), PS256 (RSA-PSS). Avoid: HS256 with shared secrets in client-side apps, RS256 with weak keys (<2048 bits), none algorithm (no signature). Never accept "alg: none" tokens. Use RS256 for client apps, HS256 only for server-to-server. Verify algorithm whitelist. Key rotation recommended.
Signature verification requires the secret key (HS256) or public key (RS256). Cannot be done client-side securely. Process: decode header and payload, recreate signature using algorithm + key, compare with token signature. Use trusted libraries: jsonwebtoken (Node.js), PyJWT (Python), jose (Go). Our decoder shows signature but does not verify - use server-side validation.
JWT expiration (exp claim) is Unix timestamp when token becomes invalid. Example: "exp": 1706659200 = Jan 30, 2025. Prevents token reuse after logout or compromise. Typical lifetimes: access tokens (15 min - 1 hour), refresh tokens (days - months). Expired tokens should be rejected server-side. No automatic invalidation - server must check exp claim. Use short lifetimes + refresh tokens.
Use JWT for: stateless API authentication, microservices communication, mobile app authentication, single sign-on (SSO), OAuth 2.0 flows. Avoid for: session management (use server-side sessions), storing sensitive data (not encrypted), long-lived tokens (use refresh tokens). Good for distributed systems, bad for centralized session control. Cannot revoke without additional infrastructure (blacklist/database).