Instantly decode, verify, and debug JSON Web Tokens to inspect payloads and header metadata without a secret key.
Paste a JWT to decode its header and payload. Provide a secret or public key to verify the signature.
The token content is decoded entirely in your browser. No data is sent to any server.
Conceptual calculation: The decoder splits the JWT into three Base64URL-encoded segments. The first segment decodes to the header JSON, the second to the payload JSON. If a secret or key is provided, the tool recomputes the signature using the specified algorithm and compares it against the provided signature.
Key assumptions: The JWT follows the standard three-segment structure (header.payload.signature). Base64URL encoding is assumed. The secret or key provided is assumed to be the correct one for verification.
Limitations and edge cases: Tokens signed with algorithms like HS256 require the exact secret used during signing. RS256 verification requires a properly formatted PEM public key. The tool cannot verify tokens signed with keys it cannot decode. Expired tokens can be decoded but will show an expiration warning.
Paste a JWT string into the input field and click "Decode Token" to instantly view the decoded header and payload. The tool parses the token entirely in your browser.
To verify a signature, select the expected algorithm and enter the secret (for HMAC algorithms) or public key (for RSA/ECDSA algorithms). The tool will indicate whether the signature is valid.
A JWT consists of three dot-separated segments. Each segment is Base64URL-encoded. The decoder reverses this process: it decodes the header and payload segments from Base64URL to UTF-8 JSON strings, then parses the JSON to display the claims.
For signature verification, the tool recomputes the signature from the header and payload using the provided key and compares it byte-by-byte with the original signature.
The header contains metadata about the token, including the signing algorithm (alg) and token type (typ). The payload contains the claims: standard claims like iss (issuer), sub (subject), and exp (expiration), plus any custom claims.
Timestamps like iat, exp, and nbf are shown in both Unix epoch format and human-readable format. A token is expired when the current time exceeds its exp value.
This tool is for debugging and educational purposes. While it can verify signatures when given the correct key, production token validation must be performed server-side with proper security controls.
Never use this tool to validate tokens in security-critical production systems. Always implement server-side signature verification, proper error handling, and secure key management.
JSON Web Tokens (JWT) are an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. The information can be verified and trusted because it is digitally signed. JWTs are commonly used for authentication, authorization, and information exchange in modern web applications.
A JWT consists of three parts separated by dots: the header, the payload, and the signature. For example: xxxxxx.yyyyyy.zzzzzz
The header is a JSON object that typically contains two fields: alg (the algorithm used to sign the token) and typ (the token type). The payload contains the claims, which are statements about an entity (typically the user) and additional metadata. The signature is computed by base64url-encoding the header and payload, concatenating them with a dot, and applying the specified algorithm with a secret or private key.
JWTs support multiple signing algorithms, each with different security properties and use cases.
| Algorithm | Type | Key Size | Common Use |
|---|---|---|---|
| HS256 | Symmetric (HMAC) | 256+ bits | Internal services, simple deployments |
| HS384 | Symmetric (HMAC) | 384+ bits | Higher security requirements |
| HS512 | Symmetric (HMAC) | 512+ bits | Maximum HMAC security |
| RS256 | Asymmetric (RSA) | 2048+ bits | OpenID Connect, public APIs |
| ES256 | Asymmetric (ECDSA) | 256 bits | Modern apps, smaller tokens |
The JWT specification defines several registered claim names that provide standardized metadata about the token.
| Claim | Name | Purpose |
|---|---|---|
| iss | Issuer | Identifies the principal that issued the token |
| sub | Subject | Identifies the subject of the token (usually the user) |
| aud | Audience | Identifies the recipients the token is intended for |
| exp | Expiration Time | Identifies when the token expires |
| nbf | Not Before | Identifies the time before which the token is not valid |
| iat | Issued At | Identifies when the token was issued |
| jti | JWT ID | Unique identifier for the token |
While JWTs are widely used, improper implementation can introduce significant security vulnerabilities. Understanding these risks is essential for building secure systems.
Avoid storing JWTs in URLs, localStorage (which is vulnerable to XSS), or browser developer tools. Prefer httpOnly cookies for browser-based applications. When tokens must be stored client-side, use encrypted storage mechanisms.
Always validate the issuer, audience, expiration, and any other critical claims on the server. Do not trust a token simply because it decoded successfully. An attacker could craft a token with arbitrary claims.
HMAC keys should be at least 256 bits. RSA keys should be at least 2048 bits. Prefer ES256 over ES384 and ES512 due to its widespread support and proven security. Avoid using "none" algorithm or HS256 with RSA public keys (algorithm confusion attacks).
JWTs are stateless; once issued, they remain valid until expiration. Implement a token blacklist or use short expiration times with refresh tokens to enable revocation when necessary.
JWTs are self-contained: they carry all necessary information within the token itself. Opaque tokens are references to data stored server-side. JWTs reduce server-side database lookups but cannot be revoked before expiration. Opaque tokens allow immediate revocation but require database queries for validation. Choose based on your revocation requirements and scalability needs.
A JWT (JSON Web Token) is a Base64URL-encoded string containing a header, payload, and signature separated by dots. To decode it, split by the dot separator and Base64URL-decode the first two segments to read the header and payload JSON.
This tool decodes entirely in your browser; no token data is transmitted to any server. However, for production credentials, avoid pasting them into any online tool out of an abundance of caution. Use local tools when handling sensitive tokens.
Yes. The header and payload can always be decoded without the key. Signature verification requires the correct secret or public key, but decoding the content does not.
Look at the exp claim in the payload. It is a Unix timestamp. If the current time is greater than exp, the token is expired. This tool automatically displays expiration status in human-readable format.
The header contains metadata about the token itself: the signing algorithm and token type. The payload contains the claims: statements about the user or subject, plus metadata like expiration and issuer.
Common causes include incorrect algorithm selection, whitespace or formatting issues in the key, using a public key when the private key is required (or vice versa), and Base64URL vs Base64 encoding confusion.
Encode and decode Base64URL strings commonly used in JWT encoding and web APIs.
Validate, format, and prettify JSON data for easier reading and debugging.
Generate HMAC-SHA256 signatures for message authentication and token validation.
Generate and test bcrypt password hashes with configurable cost factors.
Visualize OAuth 2.0 authentication flows with sequence diagrams and security recommendations.
Debug WebAuthn registration and authentication flows with CBOR decoding.
Generate cryptographically random code verifiers and challenges for PKCE-enabled OAuth.
Create strong, random passwords with customizable character sets and length parameters.