Loading...
Free JWT decoder tool to decode, verify, and analyze JSON Web Tokens instantly. View header, payload, signature with real-time validation and security analysis.
A JSON Web Token (JWT) is a compact, URL-safe token format used for securely transmitting information between parties as a JSON object. JWTs are commonly used for authentication and authorization in modern web applications, APIs, and microservices.
Each part is Base64URL encoded and separated by dots (.)
Contains token type (JWT) and signing algorithm (HS256, RS256, etc.)
Contains claims (user data, permissions, expiration time)
Verifies token integrity and authenticity
The header typically consists of two parts: the type of token (JWT) and the signing algorithm being used.
{
"alg": "HS256",
"typ": "JWT"
}The payload contains the claims - statements about an entity (typically the user) and additional metadata.
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022,
"exp": 1516242622
}The signature is used to verify the token hasn't been tampered with and to verify the sender's identity.
Symmetric algorithm using shared secret key. Fast and simple but requires secure key distribution.
Asymmetric algorithm using private/public key pair. More secure for distributed systems.
Elliptic curve algorithm. Smaller keys, faster computation, same security as RSA.
Never trust a JWT without verifying its signature
Use cryptographically strong random secrets (256+ bits)
Always include exp claim to limit token lifetime
Always transmit JWTs over secure connections
JWTs are encoded, not encrypted - avoid passwords, SSN
Check iss, aud, exp, nbf claims appropriately
Prefer RS256 over HS256 for public APIs
Use short-lived access tokens with refresh tokens
Most common use case. After user login, each subsequent request includes the JWT, allowing access to protected routes, services, and resources based on user permissions.
Enable users to access multiple applications with one set of credentials. JWT tokens are shared across domains to maintain authentication state.
Secure REST APIs and GraphQL endpoints by requiring valid JWT tokens. Include user roles and permissions in claims for fine-grained access control.
Pass authentication and authorization context between microservices. Each service can verify the JWT independently without calling an auth service.
A JSON Web Token (JWT) is a compact, URL-safe token format used for securely transmitting information between parties. It consists of three parts: header (algorithm and token type), payload (claims/data), and signature (verification). JWTs work by encoding data in Base64URL format and signing it with a secret key or private key. The recipient can decode the token to read the data and verify the signature to ensure authenticity and integrity.
Yes, you can decode a JWT without the secret key to view the header and payload contents, as they are only Base64URL encoded, not encrypted. However, you cannot verify the signature without the secret key (for HMAC algorithms) or public key (for RSA/ECDSA algorithms). Decoding shows you what's in the token, but verification proves the token hasn't been tampered with and comes from a trusted source.
HS256 (HMAC with SHA-256) is a symmetric algorithm that uses the same secret key for both signing and verifying tokens. RS256 (RSA Signature with SHA-256) is an asymmetric algorithm that uses a private key for signing and a public key for verification. HS256 is faster and simpler but requires sharing the secret key. RS256 is more secure for distributed systems as the public key can be shared freely while the private key remains secret. Use HS256 for single-server applications and RS256 for microservices or public APIs.
JWTs are encoded, not encrypted, meaning anyone with the token can decode and read its contents. Therefore, you should never store highly sensitive information like passwords, credit card numbers, or social security numbers in JWTs. JWTs are suitable for storing user IDs, roles, permissions, and non-sensitive user data. The signature ensures the token hasn't been tampered with, but doesn't hide the data. For sensitive data, use encrypted JWTs (JWE) or store sensitive information server-side and only include a reference ID in the JWT.
To verify a JWT signature: 1) For HS256/HS384/HS512, use the same secret key that was used to sign the token with HMAC algorithm. 2) For RS256/RS384/RS512, use the public key corresponding to the private key that signed the token. 3) For ES256/ES384/ES512, use the ECDSA public key. The verification process involves: taking the header and payload, applying the algorithm with the key, and comparing the result with the signature in the token. If they match, the token is valid and hasn't been tampered with.
JWT claims are statements about an entity (typically the user) and additional metadata. Standard claims include: iss (issuer), sub (subject/user ID), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Claims are important because they carry the actual data and authorization information. The exp claim is critical for security as it limits token lifetime. Custom claims can include user roles, permissions, or any application-specific data needed for authorization decisions.
JWT token validity depends on your use case. Access tokens should be short-lived (5-15 minutes) to minimize security risks if compromised. Refresh tokens can be longer-lived (days to weeks) but should be stored securely and rotated regularly. For high-security applications, use even shorter expiration times. Always implement token refresh mechanisms to maintain user sessions without requiring frequent re-authentication. Consider the balance between security (shorter tokens) and user experience (fewer re-authentications).lidity depends on your use case and security requirements. Access tokens should be short-lived (15 minutes to 1 hour) to minimize security risks if compromised. Refresh tokens can last longer (days to weeks) and are used to obtain new access tokens. For high-security applications, use shorter expiration times. For mobile apps or less sensitive applications, longer durations may be acceptable. Always implement token refresh mechanisms and consider using sliding expiration where token lifetime extends with each use.
Generate MD5, SHA-256, SHA-512 cryptographic hashes
Compare cryptographic hashes securely with timing-safe comparison
Encode and decode Base64 strings online
Generate strong, secure random passwords
Encode and decode URL strings safely
Calculate and verify file checksums for integrity