JWT Decoder. Paste any JSON Web Token
Try a sample:
Paste a JWT above to decode and inspect it
What this tool does
Free JWT decoder and validator: decode JSON Web Tokens, inspect claims, and detect security issues instantly
How JWT decoding works, what each claim means, and how to use this tool for debugging and security auditing
This JWT decoder parses any JSON Web Token and presents the header, payload, and signature in a readable, structured format. JWTs consist of three Base64URL-encoded parts: the header (algorithm and token type), the payload (the claims. User identity, expiry, permissions), and the signature. This tool decodes all three instantly in your browser. The token is never sent to any server. Decoding works without the signing secret or private key, because the header and payload are only encoded, not encrypted.
Beyond basic decoding, this tool performs a security audit on every token. It flags critical issues including the dangerous algorithm:none vulnerability, missing expiry claims, tokens that are already expired, tokens not yet valid (nbf claim in the future), and missing issuer or subject claims that are required for proper validation. These checks mirror the validation steps your server should perform before accepting a JWT. Use this tool to verify your token generation code is producing correctly formed, secure tokens.
The claims inspector automatically converts Unix timestamps for exp, iat, and nbf into human-readable dates and calculates time remaining or time since expiry. Common claims like iss, sub, aud, scope, role, and email are highlighted in a structured grid for quick inspection without scrolling through raw JSON. This makes the tool useful for debugging authentication flows, inspecting tokens from third-party OAuth providers, and investigating user sessions in production APIs.
Features and capabilities
Instant Decoding
Paste any JWT and the header and payload are decoded immediately as you type. No button click required.
Expiry Display
exp, iat, and nbf Unix timestamps converted to readable dates with a live countdown showing time remaining or time since expiry.
Security Audit
Automatically flags algorithm:none, missing exp, missing iss/sub, expired tokens, and nbf violations with warning banners.
Algorithm Detection
Identifies HS256, HS384, HS512, RS256, RS384, RS512, ES256, PS256, and the insecure 'none' algorithm from the header.
Claims Grid
Common JWT claims (sub, iss, aud, scope, role, email) displayed in a structured grid alongside timestamp-converted dates.
JSON Pretty-Print
Full header and payload displayed as syntax-highlighted, indented JSON for easy reading of nested objects and arrays.
Raw Signature
Signature segment displayed as-is so you can verify it visually or compare against expected values in debug workflows.
3 Sample Tokens
Pre-loaded sample JWTs covering a standard HS256 token, an expired token, and an RS256/OAuth2-style token for quick testing.
100% Client-Side
All decoding and validation runs in your browser. Your JWT never leaves your device, safe for production tokens.
No Signup Required
Paste and decode. No account, no API key, no rate limit.
Examples
JWT examples: standard tokens, OAuth2, and security vulnerabilities explained
Real JWT structures with annotated claims and explanations of what each part means
Standard JWTHS256 signed token: typical REST API authentication
Header:
{
"alg": "HS256",
"typ": "JWT"
}
Payload:
{
"sub": "user_123",
"name": "John Doe",
"email": "john@example.com",
"role": "admin",
"iat": 1704672000, ← issued 01 Jan 2024 00:00:00
"exp": 1704758400 ← expires 02 Jan 2024 00:00:00
}
A standard HS256 JWT containing user identity and role claims. The iat (issued-at) and exp (expiry) Unix timestamps are converted to readable dates by this tool. This token is signed with a shared secret using HMAC-SHA256. The signature verifies the payload hasn't been tampered with, but the payload is readable without the secret.
RS256 / OAuth2RS256 signed token: OAuth 2.0 access token with audience and scope
Header:
{
"alg": "RS256",
"typ": "JWT",
"kid": "key-123" ← key ID for public key lookup
}
Payload:
{
"iss": "https://auth.example.com", ← issuer
"sub": "user_789",
"aud": "https://api.example.com", ← audience
"scope": "read:messages write:messages",
"iat": 1704672000,
"exp": 4860345600
}
An RS256 token typical of OAuth 2.0 flows. The kid (key ID) in the header tells the resource server which public key to use from the JWKS endpoint to verify the signature. The iss (issuer), aud (audience), and scope claims are critical for authorisation. Your server must validate all three before accepting the token.
Security Issuealgorithm:none: unsigned token, critical security vulnerability
Header:
{
"alg": "none", ← CRITICAL: no signature
"typ": "JWT"
}
Payload:
{
"sub": "admin",
"role": "superadmin",
"exp": 9999999999
}
Signature: (empty)
Issue: Anyone can forge this token by changing "sub" to any
user ID and "role" to any privilege level.
A JWT with algorithm 'none' has no cryptographic signature and can be trivially forged. This was the basis of multiple real-world authentication bypass vulnerabilities in 2015-2016 affecting libraries that didn't explicitly reject the 'none' algorithm. This tool flags 'none' as a critical security issue. Always configure your JWT library to whitelist only your expected algorithm.
FAQ
Frequently asked questions about JWTs, JSON Web Token security, and token validation
Common questions about JWT structure, algorithms, expiry, encryption, and best practices for secure token implementation
What is a JWT (JSON Web Token)?
A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519 used to represent claims securely between two parties. It consists of three Base64URL-encoded parts separated by dots: a header (algorithm and token type), a payload (the claims. User ID, roles, expiry, etc.), and a signature that verifies the token hasn't been tampered with. JWTs are widely used for authentication and authorisation in REST APIs, OAuth 2.0 flows, and single sign-on systems.
Can I use this tool to verify JWT signatures?
This tool decodes and inspects the header and payload of any JWT. It does not verify the cryptographic signature. Signature verification requires the secret (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256, ES256), which should never be entered into a third-party tool. Use this tool to inspect claims, check expiry, and audit the token structure. Signature verification must be done server-side in your application using your secret or public key.
What are the most important JWT claims to check?
The most critical claims to validate on the server are: exp (expiry, reject tokens past this Unix timestamp), nbf (not-before, reject tokens before this time), iss (issuer, verify the token came from your expected auth server), aud (audience, verify the token is intended for your API), and sub (subject, the user identity). Missing or incorrect validation of these claims is a common source of JWT security vulnerabilities. This tool highlights missing claims as warnings so you can audit tokens before deployment.
What is the difference between HS256 and RS256?
HS256 (HMAC-SHA256) is a symmetric algorithm. Both the token issuer and the verifier use the same secret key. This is simpler but means every service that needs to verify tokens must share the secret, increasing the risk of key exposure. RS256 (RSA-SHA256) is an asymmetric algorithm. The issuer signs with a private key and verifiers use the corresponding public key. This is more secure for distributed systems because the public key can be shared freely without compromising signing capability. For microservices and OAuth 2.0, RS256 or ES256 are strongly preferred.
What does 'algorithm: none' mean in a JWT?
The 'none' algorithm means the JWT has no signature. The token is entirely unsigned and can be trivially forged by anyone. This is flagged as a critical security issue by this tool. Some JWT libraries historically accepted 'none' as a valid algorithm if not explicitly configured to reject it, leading to authentication bypasses in real systems. Always configure your JWT library to explicitly whitelist only the algorithms your system uses (e.g. only HS256, only RS256) and never accept 'none'.
Are JWTs encrypted?
Standard JWTs (JWS. JSON Web Signature) are signed but NOT encrypted. The header and payload are only Base64URL-encoded. Anyone who intercepts the token can decode and read its contents. Never put sensitive data (passwords, credit card numbers, SSNs) in a standard JWT payload. If you need encrypted tokens, use JWE (JSON Web Encryption), a separate standard that encrypts the payload. For most authentication use cases, non-sensitive identifiers (user ID, roles, email) in a signed JWT are appropriate as long as the transport layer uses HTTPS.
How long should a JWT be valid?
Short-lived tokens are a security best practice. Access tokens should typically expire in 15 minutes to 1 hour. Long enough to be practically useful, short enough to limit damage if intercepted. Refresh tokens can be longer-lived (days to weeks) but should be stored securely (httpOnly cookies, secure storage) and rotated on each use. Tokens with no expiry (missing exp claim) are flagged as an issue by this tool. They remain valid indefinitely even if the user logs out or changes their password, which is a significant security risk.
Can I decode a JWT without the secret?
Yes. Anyone with access to a JWT can decode the header and payload without knowing the secret or private key, because they are only Base64URL-encoded, not encrypted. This is by design: the payload is meant to be readable. The signature ensures the token hasn't been tampered with, but reading the contents requires no key. This is why you must never put sensitive data in the payload of a standard JWT. This tool decodes the header and payload instantly without any key. The signature is displayed as-is but not cryptographically verified.
Related Developer & Security Tools
Need a disposable email address?Stop exposing your real inbox. Get a free instant throwaway email with no signup and no trace.
Get Free Temp Mail →