JWT Encoder/Decoder
Encode and decode JSON Web Tokens (JWT). View header, payload, signature, and expiration information instantly.
What is a JSON Web Token (JWT)?
A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWTs are commonly used for authentication and authorization in modern web applications.
A JWT consists of three parts separated by dots: Header.Payload.Signature. The header contains metadata about the token, the payload contains claims (statements about the user), and the signature is used to verify the token's integrity. This tool allows you to both encode (create) and decode (inspect) JWT tokens.
JWT Structure Explained
Header
Contains the token type (JWT) and signing algorithm (e.g., HS256, RS256).
Payload
Contains claims - statements about the user and additional data.
Signature
Used to verify the token hasn't been tampered with.
Standard JWT Claims
iss (Issuer)
Identifies who issued the token
sub (Subject)
Identifies the subject of the token
aud (Audience)
Identifies the recipients of the token
exp (Expiration)
Timestamp when the token expires
iat (Issued At)
Timestamp when the token was issued
nbf (Not Before)
Timestamp before which token is invalid
JWT Signing Algorithms
HMAC (HS256, HS384, HS512) - Symmetric
HMAC uses a shared secret key for both signing and verification. The same key is used on both the issuing server and the verification server. This is the most common algorithm for internal applications where you control both sides. HS256 is the default and most widely used. HS512 provides stronger security at minimal performance cost.
RSA (RS256, RS384, RS512) - Asymmetric
RSA uses a private key for signing and a public key for verification. This is ideal for scenarios where you issue tokens in one service but verify them in multiple services, or when third parties need to verify your tokens. The public key can be safely distributed while keeping the private key secure.
ECDSA (ES256, ES384, ES512) - Asymmetric
ECDSA provides the same security as RSA with smaller key sizes and better performance. ES256 uses a 256-bit key comparable to a 3072-bit RSA key. This makes JWTs smaller and faster to sign/verify. Modern applications increasingly prefer ECDSA over RSA.
RSA-PSS (PS256, PS384, PS512) - Asymmetric
RSA-PSS is a more secure variant of RSA that uses probabilistic padding. It's considered more secure than traditional RSA but requires more recent cryptographic libraries. Use this if your target platforms support it and you need maximum security.
none - No Signature
Creates an unsigned JWT with no cryptographic signature. This is highly insecure and should NEVER be used in production. It exists only for testing scenarios where security is explicitly not required. Always reject tokens with "alg": "none" in production systems.
Common Use Cases
1. Stateless Authentication
JWTs enable stateless authentication where the server doesn't need to store session data. After a user logs in, the server issues a JWT containing the user's identity and permissions. Each subsequent request includes this JWT, allowing the server to verify the user without database lookups. This scales well for microservices and distributed systems since any service can verify the token independently.
2. Single Sign-On (SSO)
JWTs are the backbone of modern SSO implementations. When a user authenticates with a central identity provider (like Okta, Auth0, or Azure AD), they receive a JWT. This token can then be used to access multiple applications without re-authenticating. OAuth 2.0 and OpenID Connect use JWTs as ID tokens and access tokens.
3. API Authorization
REST APIs use JWTs to authorize requests. The JWT payload includes user roles and permissions, enabling fine-grained access control without server-side session state. APIs can check if a user has permission to access a resource by examining the JWT claims. This is essential for microservices where services need to make authorization decisions independently.
4. Mobile App Authentication
Mobile apps commonly use JWTs for authentication because they work well with unreliable networks. Apps store the JWT locally and include it in API requests. Since JWTs are self-contained, the app can check expiration locally before making requests. Refresh tokens (also JWTs) allow apps to obtain new access tokens without requiring the user to re-enter credentials.
5. Microservices Communication
In microservices architectures, JWTs enable secure service-to-service communication. When a user request enters the system, the gateway issues a JWT that's passed between services. Each service can verify the JWT and extract user context without calling a central authentication service. This reduces coupling and improves performance.
6. Debugging Authentication Issues
When authentication fails in production, developers need to inspect JWTs to diagnose issues. This tool lets you decode tokens from logs or network traces to check expiration times, verify claims, identify malformed tokens, and understand why authentication failed. You can verify that the issuer, audience, and claims match expectations without exposing secrets.
Frequently Asked Questions
Are JWTs encrypted?
No. Standard JWTs are signed (to prevent tampering) but not encrypted. Anyone can decode a JWT and read its contents - you don't need the secret key. This is by design: JWTs are meant for authentication/authorization, not secrecy. There is a separate standard (JWE - JSON Web Encryption) for encrypted tokens, but it's less common.
How long should JWTs be valid?
Short lifetimes are more secure. Access tokens typically last 15-60 minutes, while refresh tokens last days or weeks. Short-lived access tokens limit the damage if a token is stolen. Use refresh tokens to issue new access tokens without re-authenticating the user. Balance security (shorter is better) with user experience (longer means fewer refreshes).
Can I revoke a JWT before it expires?
Not easily - JWTs are stateless by design. Common solutions: maintain a token blocklist on the server (defeats the stateless advantage), use short expiration times (15-30 minutes), or include a "version" claim and increment it when you need to invalidate all user tokens. For immediate revocation needs, consider using opaque tokens instead of JWTs.
Where should I store JWTs in a web app?
HttpOnly cookies are most secure (JavaScript can't access them, preventing XSS theft). LocalStorage is convenient but vulnerable to XSS attacks. SessionStorage is slightly better than LocalStorage (cleared when tab closes). Memory storage (JavaScript variable) is most secure but lost on page refresh. Use HttpOnly cookies for production apps.
What's the difference between access tokens and refresh tokens?
Access tokens are short-lived (15-60 mins) and used to access protected resources. Refresh tokens are long-lived (days/weeks) and used only to obtain new access tokens. This pattern limits exposure: if an access token is stolen, it expires soon. Refresh tokens should be stored more securely and can be revoked server-side.
Should I use HS256 or RS256?
Use HS256 if you control both token creation and verification (single service, monolith). Use RS256 if multiple services verify tokens or third parties need to verify (microservices, public APIs). RS256 allows you to distribute the public key safely while keeping the private key on one server. ES256 is a modern alternative to RS256 with better performance.
Can I decode a JWT without the secret?
Yes! JWTs are Base64-encoded, not encrypted. You can decode and read any JWT without knowing the secret. The secret is only needed to verify the signature (prove the token wasn't tampered with) or to create new signed tokens. This tool decodes JWTs without requiring secrets. Never put sensitive data in JWTs.
What happens if I don't verify the JWT signature?
Attackers can create fake tokens with arbitrary claims. ALWAYS verify signatures server-side. An attacker could decode a JWT, change the "role" from "user" to "admin", and if you don't verify the signature, your server will accept the forged token. Signature verification is critical - it's the only thing preventing token tampering.
Security Considerations
- • JWTs are not encrypted by default - anyone can decode and read the contents
- • Never store sensitive information (passwords, credit cards) in JWT payload
- • Always validate JWT signatures on the server side
- • Use HTTPS to prevent token interception
- • Implement token expiration and refresh mechanisms
- • The encoder mode is for testing/development only - use proper JWT libraries in production
- • Never expose your secret keys - keep them server-side only
Privacy & Security
All JWT encoding and decoding happens entirely in your browser using the Web Crypto API. Your tokens and secrets never leave your device. This tool runs 100% client-side for complete privacy and security.