JWT Decoder Online
Decode JSON Web Tokens instantly in your browser. Inspect JWT headers, payloads, claims, and signatures, view token expiration details, and copy or download decoded results without sending your token to a server.
JWT Input
Your token is decoded locally in your browser and is never uploaded to a server.
Decoding does not verify a JWT's signature or establish that its claims are trustworthy. Avoid pasting production credentials into tools on devices you do not control.
Header
Payload
Signature
All Developer Tools
Browse free online tools for JSON, HTML, CSS, XML, JavaScript, data conversion, and everyday development tasks.
Try a different search term or select another category.
What Is a JWT Decoder?
A JWT Decoder Online is a tool that reads a JSON Web Token and displays its header, payload, claims, and signature section in a more understandable format. Instead of manually separating and decoding the token, you can paste it into the decoder to inspect its contents and troubleshoot authentication or API issues.
JWT stands for JSON Web Token. It is a compact, URL-safe token format commonly used to transmit claims between applications and services. JWTs frequently appear in authentication systems, API authorization, single sign-on, and identity workflows.
Jomatter's online JWT decoder helps developers, API testers, security engineers, and students inspect token contents in one place. You can examine the decoded JSON, review standard claims, check timestamp values, and investigate token expiration without writing a separate decoding script.
Example JWT Structure
A typical signed JWT contains three Base64URL-encoded or encoded components separated by periods: a header, a payload, and a signature. The header describes token metadata, the payload contains claims, and the signature helps a receiving application verify the token's integrity.
Example Decoded Header
Example Decoded Payload
In this example, the header identifies the HMAC SHA-256 algorithm, while the payload contains a subject identifier, a name, an issued-at timestamp, and an expiration timestamp. These values describe the token's contents; they do not by themselves prove that the token is authentic.
Important: Decoding a JWT is not the same as verifying it. Anyone who possesses a typical signed JWT can decode its header and payload. Always verify the signature and validate the relevant claims before trusting a token.
How to Decode a JWT Online
Use these steps to inspect a JSON Web Token and understand the information it contains.
Copy the token from a development API response, authentication test, or authorization header. A typical signed JWT has three parts separated by periods.
Enter the complete JWT in the input field, without adding extra characters or removing the separators between its parts.
Review the decoded JSON to identify the signing algorithm, token type, subject, issuer, audience, and other claims included in the token.
Review claims such as iat, nbf, and exp. Convert their Unix timestamps into readable dates and compare them with the current time.
Use the appropriate verification key and supported algorithm if you need to check whether the token's signature is valid. Decoding alone does not perform this check.
Copy the header or payload JSON for debugging and documentation, but remove or protect sensitive claim values before sharing the output.
If the token cannot be decoded, check whether it is complete, whether the sections are separated correctly, and whether the token uses the expected compact serialization format. Encrypted JWTs and other token formats require different handling from ordinary signed JWTs.
Key Features of an Online JWT Decoder
A JWT decoder makes token inspection easier by separating its components and presenting encoded data in a readable form. The available inspection and verification features depend on the tool's implementation.
Instant JWT Decoding
Parse a supported JSON Web Token to inspect its header, payload, claims, and signature section without manually decoding each part.
JWT Header Viewer
Review header parameters such as alg and typ, along with supported custom parameters that describe the token.
JWT Payload Decoder
Inspect decoded JSON claims, including identifiers, timestamps, permissions, and custom data included in the payload.
Standard Claim Inspection
Understand common claims such as iss, sub, aud, exp, nbf, and iat.
Expiration and Time Checks
Convert supported Unix timestamp claims into human-readable dates to investigate expired tokens or tokens that are not yet active.
JWT Signature Checking
Where signature verification is supported, check a token against the appropriate secret or public key and a permitted algorithm.
Readable JSON Results
Examine formatted header and payload data to help identify missing claims, incorrect values, unexpected timestamps, or configuration problems.
Browser-Based Processing
Process token contents locally in your browser without requiring a separate server to decode the token.
Security distinction: A decoded payload, a valid signature, and an authorized request are three different things. Your application must verify the token correctly and enforce its own issuer, audience, expiration, and permission requirements.
What Is a JSON Web Token?
A JSON Web Token (JWT) is a compact format for representing claims as a JSON object. It is commonly used to transmit information between parties in authentication and authorization systems. A JWT may be signed, encrypted, or protected using other mechanisms depending on the format and implementation.
A typical signed JWT using compact serialization consists of three sections separated by periods:
1. JWT Header
The header contains token metadata, commonly including the algorithm used to protect the token and the token type. Other parameters may identify a key or provide additional metadata.
2. JWT Payload
The payload contains claims, which are statements about a subject or additional information relevant to the token. Claims may include a user identifier, issuer, audience, expiration time, or application-specific fields.
3. JWT Signature
The signature protects the integrity of a signed token. A receiving application can verify it using the appropriate algorithm and key to determine whether the token was signed correctly and has remained unchanged.
The header and payload in a typical signed JWT are Base64URL-encoded, not encrypted. They can be decoded without the signing key. A signature does not hide the token's contents, and it does not automatically establish that every claim is appropriate for the receiving application.
Standard JWT Claims Explained
JWT claims provide information about a token's subject, issuer, intended recipient, and validity period. The meaning and validation requirements of a claim depend on the application using the token.
| Claim | Name | Meaning |
|---|---|---|
iss |
Issuer | Identifies the principal or system that issued the token. |
sub |
Subject | Identifies the subject of the token, often a user or another entity. |
aud |
Audience | Identifies the intended recipient or recipients of the token. |
exp |
Expiration time | Specifies the time after which the token must not be accepted, subject to applicable validation rules and permitted clock-skew handling. |
nbf |
Not before | Specifies the time before which the token must not be accepted. |
iat |
Issued at | Indicates when the token was issued. |
jti |
JWT ID | Provides an identifier for the token, which can help systems track individual tokens. |
scope |
Scope | A commonly used application claim that describes the permissions or access scope associated with a token. |
roles |
Roles | A custom claim often used to represent application-specific roles or access categories. |
The claims iss, sub, aud, exp, nbf, iat, and jti are registered JWT claim names. Claims such as scope and roles are commonly used by applications but are not interchangeable universal authorization rules.
Remember: Displaying a claim does not mean it has been validated. Your application should check the claims it requires and enforce the expected issuer, audience, time limits, and permissions.
JWT Signature Verification
Decoding a JWT reveals its encoded information, but it does not establish that the token was issued by a trusted party or that its contents have not been changed. Signature verification uses a cryptographic algorithm and the appropriate key to check the signature.
Common JWT signing algorithms include the following:
HMAC Algorithms
HS256, HS384, and HS512 use a shared secret to create and verify a message authentication code. The issuer and verifier must protect the same secret.
RSA Algorithms
RS256, RS384, RS512 use RSA signatures. Verification normally uses the corresponding public key, while signing requires the private key.
ECDSA Algorithms
ES256, ES384, ES512 use elliptic-curve digital signatures. Verification uses the corresponding public key.
RSA-PSS Algorithms
PS256, PS384, PS512 use RSA Probabilistic Signature Scheme signatures. Verification requires the appropriate public key and compatible algorithm support.
Protect your keys: Never paste a production private key or sensitive shared secret into an online tool. For verification, use a public key where applicable or a non-production test secret when appropriate. Confirm that any verification happens locally before using a tool with sensitive test credentials.
Signature verification alone is not sufficient to authorize a request. A secure application must also enforce an explicit algorithm allowlist and validate the token's issuer, audience, expiration, not-before time, and required permissions according to its security requirements.
JWT Expiration and Timestamp Checking
JWT timestamps help applications determine when a token was issued, when it can become active, and when it must no longer be accepted. Registered time claims such as iat, nbf, and exp are generally expressed as NumericDate values, measured in seconds from the Unix epoch.
Example JWT Time Claims
iat: Indicates the token's issue time. It does not, by itself, prove that the token is valid.nbf: Indicates when the token can begin to be accepted. A token may be rejected if it is used too early.exp: Indicates when the token expires. A token must not be accepted after its expiration time, subject to applicable validation rules.
A JWT expiry checker can help you understand timestamp claims and identify common timing problems. However, the actual validity decision depends on the current time, any permitted clock-skew allowance, and the validation rules of the receiving application.
Tip: Check whether timestamp values use seconds or milliseconds. Standard JWT NumericDate claims are expressed in seconds, while many JavaScript date functions work with milliseconds. Confusing these units can produce incorrect dates and expiry calculations.
Common JWT Errors and Troubleshooting
A token may fail authentication because it is expired, incorrectly signed, intended for a different audience, or rejected by the application's validation rules. Inspecting the decoded token can help narrow down the cause.
| Issue | What it means | What to check |
|---|---|---|
| Expired token | The expiration time has passed. | Check the exp claim, system clock, and token refresh flow. |
| Invalid signature | The signature does not verify with the selected algorithm and key. | Confirm the token has not changed and that the verification key and algorithm are correct. |
| Token not yet valid | The token's not-before time is in the future. | Review nbf, the current time, and permitted clock skew. |
| Wrong audience | The token audience does not match the expected recipient. | Compare the aud claim with the application's configured audience. |
| Untrusted issuer | The token was issued by an unexpected identity provider or issuer. | Validate the iss claim against the trusted issuer configuration. |
| Unsupported algorithm | The application does not permit or support the indicated signing algorithm. | Check the application's explicit algorithm allowlist and key configuration. |
| Malformed token | The token does not follow the expected encoding or serialization structure. | Check the number of sections, separators, Base64URL encoding, and completeness of the input. |
| Unsigned token | The header indicates an unsecured token using alg: none. |
Reject unsecured tokens unless a narrowly defined, explicitly permitted use case requires them. |
When troubleshooting, distinguish a decoding problem from a signature failure and a claim-validation failure. Each points to a different part of the token or application configuration.
Is a JWT Encoded or Encrypted?
A typical signed JWT is encoded, not encrypted. Its header and payload are usually Base64URL-encoded JSON, so someone who obtains the token can decode and read those sections without knowing the signing secret.
Encoding
Encoding changes how data is represented. Base64URL encoding makes the JWT components suitable for use in a URL-safe token format, but it does not make their contents confidential.
Signing
Signing provides integrity protection and helps the receiving application verify the token's origin using a trusted key and permitted algorithm. It does not conceal the payload.
Encryption
Encryption protects confidentiality by making content unreadable without the appropriate decryption key. Encrypted JWTs use a different structure and require compatible decryption support.
Safe Token Design
Keep token claims minimal, use appropriate expiration times, protect signing keys, and never rely on Base64URL encoding to secure sensitive information.
Security warning: Do not store passwords, credit-card numbers, private keys, or other confidential data in an ordinary JWT payload. Use an appropriate encrypted design when confidentiality is required, and enforce token verification and authorization on the server.
Who Uses a JWT Decoder?
A JWT token decoder is useful for anyone who develops, tests, or maintains systems that rely on token-based authentication and authorization.
Backend Developers
Inspect token claims, troubleshoot authentication middleware, and investigate problems with token verification or session handling.
API Developers
Examine access tokens used in API requests, identify claim mismatches, and debug authorization workflows during development.
QA Engineers
Test login flows, token expiration behavior, claim requirements, and access permissions across different scenarios.
Security Engineers
Review token metadata, signing algorithms, expiration policies, and claim-validation requirements during controlled security testing.
DevOps Engineers
Troubleshoot token-based authentication in API gateways, identity integrations, and deployment environments.
Students and Learners
Understand JWT structure, Base64URL encoding, standard claims, timestamps, and the difference between decoding and verification.
Is My JWT Token Safe?
Jomatter's JWT Decoder is designed to process tokens locally in your browser, without requiring the token to be sent to a separate decoding server. This approach can help when inspecting development tokens and test payloads.
However, JWTs may contain session identifiers, user information, access permissions, or other sensitive claims. A valid token may also grant access to protected resources. Anyone who obtains a bearer access token may be able to use it until it expires or is otherwise invalidated, depending on the application's design.
Security tip: Avoid pasting production access tokens, private signing keys, or live shared secrets into online tools. Use test tokens and non-production credentials whenever possible, and follow your organization's security policies.
Before trusting a JWT, ensure the receiving application verifies the signature using an explicitly allowed algorithm, validates relevant claims, checks expiration, and applies authorization rules. A readable payload alone is never proof that the token is trustworthy.
Frequently Asked Questions
What is a JWT decoder?
A JWT decoder is a tool that parses a JSON Web Token and displays its header, payload, and claims in readable form. It helps developers understand token contents and troubleshoot authentication problems.
Is this JWT decoder free?
Jomatter's JWT Decoder is designed for free online use without a separate desktop installation. The tool's available decoding and verification features depend on its implementation.
Does decoding a JWT verify its signature?
No. Decoding reveals the token's contents, but it does not prove authenticity. Signature verification requires the appropriate key, a permitted algorithm, and correct verification logic.
Can I check whether a JWT is expired?
You can inspect the exp claim to determine the token's stated expiration time. A complete validity decision also depends on the current time, permitted clock skew, and the receiving application's validation rules.
What is the difference between encoding and encryption?
Encoding changes a value's representation and does not provide confidentiality. Encryption makes content unreadable without the appropriate key. Ordinary signed JWTs use Base64URL encoding for their header and payload rather than encryption.
Can I verify an HS256 JWT?
Yes, with a verifier that supports HS256 and the correct shared secret. Keep production secrets private and use a non-production secret when testing online tools.
Can I verify an RS256 JWT?
Yes, with a verifier that supports RS256 and the corresponding public key. Signature verification should also use the algorithm explicitly permitted by the receiving application.
Is my JWT token sent to a server?
Jomatter's JWT Decoder is designed for client-side processing, so decoding does not require sending the token to a separate server. Avoid using production tokens unless your security requirements permit the workflow.
What do the three parts of a JWT mean?
A typical signed JWT contains a header, payload, and signature separated by periods. The header contains token metadata, the payload contains claims, and the signature helps a verifier check integrity.
What are the exp, iat, and nbf claims?
The exp claim specifies expiration, iat indicates issue time, and nbf specifies when the token can begin to be accepted. These time claims are commonly represented as NumericDate values in seconds.
Why is my JWT invalid?
Possible causes include malformed token sections, an incorrect signature, an expired token, a future not-before time, an unexpected issuer or audience, or an unsupported algorithm. Check the relevant claim and verification settings.
Can I decode an encrypted JWT?
A normal decoder for signed JWTs cannot reveal an encrypted JWT's protected contents without compatible decryption support and the appropriate key. Encrypted tokens use a different structure from ordinary three-part signed JWTs.
Is a decoded JWT safe to trust?
No. Decoded data is only readable data. The application must verify the signature, validate the required claims, and enforce authorization rules before trusting the token.
Can I use a JWT decoder on mobile?
You can open an online JWT decoder in a modern mobile browser. The experience depends on the page layout, browser capabilities, and the token's size.