JWT Decoder Free Online
Decode and inspect JWT (JSON Web Tokens) instantly. View the header algorithm, payload claims, expiry time, issued-at date, and raw JSON for all three parts. Validates token structure. Runs entirely in your browser — your tokens are never uploaded or stored.
Paste your JWT token below
Header
Raw JSON
Payload
Raw JSON
Signature
Base64url-encoded signature (not decoded — verification requires the secret key)
Pro — JWT signature verification (HS256/RS256), batch decode, token generator, API access
API access · Priority queue · Team workspace
How It Works
Paste the JWT Token
Paste any JWT token string into the input box. JWT tokens consist of three Base64url-encoded parts separated by dots: the header (algorithm and token type), the payload (claims), and the signature. You can get tokens from browser developer tools network tabs, from API responses, from authentication headers in logs, or from your application's debug output. Click Sample JWT to see a pre-built example.
Click Decode
Click Decode to split the token at the dots, Base64url-decode each part, parse the JSON, and display the results in three panels. The decoder validates that the token has exactly three dot-separated parts and that the header and payload are valid JSON. It checks whether the token is expired by comparing the exp claim against the current time, and displays human-readable timestamps for exp, iat, and nbf.
Inspect Claims & Metadata
Review all three sections. The Header panel shows the signing algorithm and token type. The Payload panel shows all claims with timestamps converted to readable dates. The Signature panel shows the raw Base64url-encoded signature — note that signature verification requires the secret key and is a Pro feature. Use the Raw JSON toggles to see the exact JSON structure for debugging or copying into other tools.
JWT Decoder Features
Full claim inspection with expiry checking and human-readable timestamps
All Three Parts Decoded
Decodes all three JWT parts: the header (containing the algorithm like HS256, RS256, ES256 and the token type), the payload (containing all registered and custom claims), and the signature (shown as raw Base64url for reference). The header and payload are displayed both as structured claim tables and as pretty-printed raw JSON for full visibility into the token contents.
Expiry & Timestamp Parsing
Standard JWT timestamp claims (exp expiration time, iat issued at, nbf not before) are Unix timestamps (seconds since epoch). This tool converts all three to human-readable local and UTC date strings. The status badge clearly shows whether the token is currently valid, expired, or not yet valid based on exp and nbf relative to the current time.
Structure Validation
Validates that the token is properly structured: exactly three dot-separated parts, each part is valid Base64url, and the header and payload decode to valid JSON. Common errors like extra whitespace, missing parts, or truncated tokens are detected and reported with clear messages. This helps identify tokens that have been accidentally truncated when copied from logs or network traces.
Registered Claim Labels
Standard registered claims defined in RFC 7519 — sub (subject), iss (issuer), aud (audience), exp (expiration), iat (issued at), nbf (not before), jti (JWT ID) — are labeled with their full names for clarity. Custom application claims are displayed as-is with their raw key names and values.
No Signature Verification (Free)
Decoding reads and displays the payload claims without verifying the signature. This is sufficient for inspecting token contents during debugging, but you should never trust the claims of a JWT without verifying its signature in production code. The tool clearly indicates that the signature is not verified. Pro adds HS256, RS256, and ES256 signature verification with secret/public key input.
100% Private
JWT tokens often contain sensitive user identity claims, permissions, and application-specific data. This tool processes all tokens entirely in your browser — no token is ever transmitted to a server, logged, or stored. You can safely paste production tokens, admin session tokens, and service account credentials without risk of exposure to third-party services or analytics systems.
Free vs Pro
| Feature | Free | Pro |
|---|---|---|
| Decode header & payload | ||
| Expiry & timestamp check | ||
| HS256/RS256/ES256 verification | — | |
| JWT generator / builder | — | |
| Batch decode multiple tokens | — | |
| REST API access | — |
Frequently Asked Questions
A JSON Web Token (JWT) is a compact, self-contained way of securely transmitting information between parties as a JSON object. JWTs consist of three parts separated by dots: a Base64url-encoded header (containing the token type and signing algorithm), a Base64url-encoded payload (containing claims — statements about an entity like user ID, roles, and expiration time), and a cryptographic signature. JWTs are commonly used for authentication (storing a logged-in user's identity in a session token) and authorization (passing permissions between microservices).
It depends on the tool. Many online JWT decoders send your token to their server for decoding, which means your claims (user ID, email, roles) and the token itself (which may still be valid and usable for authentication) are exposed to a third party. This tool decodes entirely in your browser — nothing is transmitted. You can verify this by opening your browser's network tab before pasting a token and confirming no requests are made.
RFC 7519 defines standard registered claims: sub (subject — who the token is about, typically a user ID), iss (issuer — who issued the token), aud (audience — who the token is intended for), exp (expiration time — Unix timestamp when the token expires), iat (issued at — when the token was created), nbf (not before — token is not valid before this time), and jti (JWT ID — unique identifier for the token). Applications add their own custom claims alongside these.
HS256 (HMAC-SHA256) uses a symmetric shared secret — the same secret key is used to both sign and verify the token. This is simple but requires that all parties that need to verify tokens also have access to the secret. RS256 (RSA-SHA256) uses an asymmetric key pair — the private key signs the token and the public key verifies it. This allows the issuer to publish the public key so any service can verify tokens without knowing the signing secret, which is the correct approach for distributed microservices and third-party token validation.
No — not without verifying the signature. JWT claims can be read by anyone because the payload is just Base64url-encoded (not encrypted). A malicious actor could craft a token with any claims they choose. The signature is what prevents tampering — if the signature verification fails, the token was modified or forged and its claims must not be trusted. Always verify the JWT signature in your application code before trusting any claims for authentication or authorization decisions.
A session cookie contains only an opaque session ID — the server must look up the session in a database or cache for every request to find the associated user data. A JWT is self-contained — it carries the user data directly in the token, so the server can verify and read the user's identity without a database lookup. JWTs are stateless and scale horizontally without shared session storage, but cannot be individually revoked before expiry without maintaining a deny list. Session cookies are easier to revoke but require server-side state.