JWT Decoder Online – Verify & Inspect

Loading…

JWT Decoder Online – Verify & Inspect | MyToolSpace

What Is a JWT Decoder, and What Does MyToolSpace Inspect?

A JWT decoder turns the base64url-encoded header and payload of a JSON Web Token into readable structured data. It is useful when an API rejects requests, a login session behaves unexpectedly, or a team needs to confirm which issuer, subject, audience, scope or expiration was put into a token. MyToolSpace combines the everyday decode action with a claims explorer, expiration analyzer and optional cryptographic verification so developers can investigate the token from several perspectives in one workspace.

The most important distinction is that decoding is not validation. Anyone holding a typical signed JWT can decode its contents without a key, and a malicious party can assemble a token with any claims they wish. Trust requires verifying the signature against an appropriate key selected from a trusted source, restricting accepted signing algorithms and checking relevant claims against the receiving application. A cleanly formatted token or a green-looking timestamp is not enough.

The live tool describes locally executed parsing and verification, plus comparison, bulk analysis, generation, key support and export. Use these as developer and audit conveniences, not as replacements for the receiving server’s own authentication and authorization checks. Make sure any example tokens you publish have no active credentials or sensitive personal information.

Decode: Read header parameters and claims without claiming authenticity.
Verify: Check a signature with the matching key and allowed algorithm.
Validate: Apply issuer, audience, time and application-specific policy.
Inspect: Review risks, differences and expiry details before debugging.

JWT Structure Explained: Header, Payload and Signature

A common signed JWT uses the compact form header.payload.signature. Each segment is base64url-encoded and separated by a period. The protected header commonly contains typ and alg; it may include kid to identify a signing key. The payload contains claims such as sub, iss, aud and exp. The final segment holds a signature or message authentication code computed over the encoded header and payload.

Base64url is a transport encoding, not secrecy. If you paste a signed token into a decoder, you can generally read its claims without a private key. That is why credentials, passwords, API secrets, card details and other sensitive information should not be placed in an ordinary JWS payload. Signing helps protect integrity and detect tampering; it does not hide contents from someone who possesses the token.

Not every token-shaped input is the same. An unsecured JWT can use alg none and has no meaningful signature protection; reject such tokens wherever signatures are required. Compact JWE has five segments and is encrypted; this tool documents JWE detection and protected-header inspection rather than pretending that it can reveal encrypted claims without decryption keys. Some applications also use opaque bearer tokens that cannot be decoded as JWTs.

Decode vs Verify vs Validate: Three Different JWT Checks

Decoding answers: what does the token say? It parses a readable header and claims. Signature verification answers: was the signed content authenticated by the expected key without alteration? Validation goes further: should this specific API accept that token for this use, at this moment, under its security policy? Mixing these steps is a frequent cause of broken authentication.

A verifier needs the correct cryptographic key and implementation for the allowed algorithm. HS256 uses a shared secret, whereas RS256, ES256 and EdDSA normally verify with a public key. Once a signature succeeds, the receiving application still needs to check trusted issuer, intended audience, time limits and relevant permissions. Depending on the environment, token type, nonce, authorized party, maximum age and revocation state can matter too.

MyToolSpace is useful for independently inspecting a failing token and confirming whether a candidate key matches. The page’s audit score is an educational diagnostic; it is not proof that a real service has checked all required claims or authorization rules. A token can be correctly signed and still be unacceptable because it was issued for another audience or because a user no longer has permission.

JWT Claims Guide: exp, iat, nbf, iss, aud, sub and jti

Registered JWT claims have concise names. iss identifies the issuing authority; sub identifies the subject; aud names intended recipients; exp gives the expiration instant; nbf states when a token becomes usable; iat records issue time; jti is a token identifier. Different applications may use scopes, roles, permissions, tenant information or custom identifiers, but the meanings of custom claims must be defined by the issuing system.

The timestamp claims exp, nbf and iat use NumericDate values measured in seconds from the Unix epoch. Treating a millisecond timestamp as seconds can produce nonsensical expiration displays. Expiration and not-before decisions should use reliable server clocks and a deliberately limited skew allowance. A decoder can show how a token is written, but it cannot know whether the issuer or audience is genuinely trusted in your deployment.

For a request to /orders, an API typically needs more than sub: it must check an appropriate scope or permission and confirm the user can access the specific order. Do not place confidential permissions data or personal secrets in payload fields under the assumption that signing encrypts them. Prefer stable claim naming and minimal disclosure.

JWT Signature Algorithms: HS256, RS256, PS256, ES256 and EdDSA

HS256, HS384 and HS512 are HMAC algorithms that use a shared secret to sign and verify. They can be efficient inside a carefully controlled trust boundary, but anyone possessing the signing secret can create tokens. Use high-entropy random keys, keep them outside browser clients and rotate them according to a documented key policy. Increasing a digest size is not a substitute for a strong key and sound verification.

RS256/384/512 use RSA signatures, while PS256/384/512 use RSA-PSS. ES256/384/512 use ECDSA with corresponding elliptic curves, and EdDSA commonly means Ed25519 in this tool. These asymmetric families let an identity provider retain the private signing key while APIs verify using public keys. Algorithm choice depends on ecosystem support, key management, performance, signature size and an organization’s cryptographic requirements.

The live page documents verification for these families using browser cryptography and key imports from shared secret, PEM, JWK or X.509 certificate workflows as applicable. For production systems, pin an explicit set of accepted algorithms and expected key types; never select a more permissive algorithm solely because the untrusted JWT header requests it. Verify imported public keys against a trusted issuer or secure configuration.

Check JWT Expiration and Debug 401 Unauthorized Errors

The expiry timeline helps diagnose unexpected authentication failures. If exp is earlier than the server’s present time, an otherwise valid token should not be accepted. If nbf is in the future, the token is not yet eligible for use. iat documents issuance and can support an application’s maximum-token-age rule, but iat itself is not interchangeable with exp.

Clock skew is another practical issue. A client machine with an inaccurate clock may display a surprising countdown, while the API evaluates validity using its own clock. Compare the token’s NumericDate values to a trusted UTC reference and check whether a narrow configured tolerance explains the difference. A large blanket tolerance can weaken expiration safeguards.

When investigating a 401 response, inspect more than time: the API might reject an invalid signature, wrong key ID, mismatched audience, unexpected issuer, unsupported algorithm or missing Authorization header. An HTTP 403 response may instead indicate insufficient authorization despite a valid token. MyToolSpace offers convenient timestamps and claims analysis, but only your application logs and policy can confirm the exact reason.

JWT Security Audit and RFC 8725 Best Practices

A security audit can flag patterns that warrant investigation: alg none, missing exp, implausibly long lifetimes, absent issuer or audience, potential algorithm confusion and sensitive-looking fields. The MyToolSpace page describes a 0–100 audit score based on JWT security guidance including RFC 8725. Treat the score as a heuristic checklist and review each finding in context rather than using a number as a certificate.

The core defense is to verify a token according to a preconfigured trust policy. Maintain an issuer allowlist, validate intended audience, pin permitted algorithms, resolve keys from trusted sources and reject malformed or unsecured tokens. Be cautious with kid processing: it is an untrusted identifier that should be matched against a constrained trusted key set, not used as an arbitrary file path or network URL.

Keep access tokens short-lived according to system needs; protect refresh tokens and design revocation where required. Avoid logging raw bearer tokens or putting them in URLs. Security tools are helpful during authorized development and testing, but production authorization still depends on server enforcement, resource permissions and ongoing monitoring.

Weak HMAC Secret Testing and Defensive Key Hygiene

A JWT signed with HS256 can fail in practice because the shared secret is predictable. Common strings and copied demonstration secrets give attackers a much smaller search space than a randomly generated cryptographic key. The page describes a browser-local tester for common weak HMAC secrets intended for defensive checks of tokens you own or are authorized to audit.

Only use the tester against your own systems or with explicit permission. A successful dictionary match means that secret needs rotation and potentially an incident review, not merely a cosmetic score adjustment. Absence of a dictionary hit does not prove the key has sufficient entropy; the test only examines candidate secrets in its configured list.

For new deployments, obtain strong random key material from a trusted cryptographic source and protect it in a secrets manager. Decide whether keys are represented as raw UTF-8, Base64, Base64url or hexadecimal and configure all issuers and verifiers consistently. A mismatch between the encoded secret string and the intended decoded bytes often produces false verification failures.

Test only keys and tokens within your remit.

Generate Signed JWTs and Browser-Based Test Key Pairs

The Generate tab supports test-token creation with an editable header and claims payload. Signing options include matching shared secrets or asymmetric private keys; the page also documents locally generated RSA, EC and Ed25519 key pairs with PEM/JWK export. This can help reproduce an authentication bug, teach JWT structure or build controlled test fixtures without writing a standalone signing script.

Do not confuse generated test credentials with production identity-provider administration. A token signed by a locally generated key will not be accepted by an API unless that API is deliberately configured to trust the corresponding issuer and public key. Use fictitious subjects and test audiences in examples. Save private keys only in secured locations and never commit them to source control or paste them into shared bug reports.

For integration testing, deliberately construct valid and invalid cases: expired tokens, wrong audience, wrong issuer, unknown kid, modified payload, missing claims and unsupported algorithms. Use the resulting errors to confirm that the production validator rejects inputs correctly, not to weaken validation so a fabricated token passes.

Compare JWTs and Analyze Many Tokens in Bulk

Two access tokens can look similar while differing in important security-relevant fields. The Compare tab highlights header and claim additions, removals and changes. This is useful when investigating refresh cycles, identity-provider migrations, newly introduced roles, unexpected scopes or issuer configuration drift. Differences should be interpreted against your intended authorization model.

The Bulk analyzer processes multiple tokens supplied as lines or through a supported file input and summarizes details including algorithm, subject, issuer and expiration status. The page documents JSON and CSV report exports. Such summaries make review more efficient, but they do not mean every token has been cryptographically verified unless verification is explicitly run with the appropriate keys.

Bearer tokens are credentials, even when their contents are readable. Minimize collection, use short-lived test values whenever possible, restrict downloaded reports, and remove or mask identifying claims before sharing them. The live page describes a privacy wipe for local data; nonetheless device compromise, screen capture and exported files remain separate risk factors.

JWT Privacy: Browser Processing, Sensitive Tokens and Wipe Controls

The MyToolSpace page states that its decoding, signature verification, signing and key handling execute in the browser using Web Crypto and JavaScript. It also describes local history and a privacy wipe. This design reduces the need to submit tokens to a remote verification service; the page’s documentation is not independently a security audit of the deployed application or any third-party scripts.

Before pasting a production JWT, consider the token’s privileges, active lifetime and organizational policy. Anyone who copies a valid bearer token may be able to act with the permissions it grants until expiry or revocation. Prefer a redacted test token or a temporary credential with limited scope, and avoid placing tokens into screenshots, issue trackers, source repositories or analytics events.

When using exported token reports or private-key material, protect the resulting files as carefully as the original input. Local browser operation does not automatically secure an infected device, browser extension, downloaded backup or clipboard. The wipe control can clear tool state, but it cannot retract a credential already copied or exposed elsewhere.

JWT in OAuth 2.0, OpenID Connect and JWKS-Based APIs

JWTs often appear in identity systems, but OAuth 2.0 does not require every access token to be a JWT. An authorization server may issue opaque access tokens, while OpenID Connect uses ID tokens to communicate authentication-related identity claims to a client. An access token and an ID token are not interchangeable; they serve different audiences and must be validated for their intended purpose.

When a service uses asymmetric JWTs, a trusted issuer may publish a JSON Web Key Set (JWKS) with public verification keys. The JWT header’s kid can help select the appropriate key among those the issuer publishes. A verifier must bind that lookup to the configured issuer and expected algorithms, handle key rotation safely and reject untrusted or unexpected key references.

During troubleshooting, compare issuer, audience, scopes and key IDs with your identity-provider settings. A JWT decoder can expose the text of these fields and assist with signature checks, but only the application knows which audiences, scopes, tenants, nonce conditions and claims are acceptable in its security context.

OAuth 2.0: An access token may be JWT or opaque.

JWS vs JWE vs Opaque Tokens: What Can Be Decoded?

A JSON Web Signature (JWS) compact serialization commonly has three dot-separated sections, and the token’s payload remains readable after base64url decoding. Its signature is intended to protect integrity and authenticity. A JSON Web Encryption (JWE) compact serialization usually has five sections and encrypts content; possession of a token alone does not reveal the encrypted plaintext.

The tool documents detection of JWE and inspection of protected-header information, not universal decryption. If an input cannot be decoded as a three-part JWT, first check whether it is a five-part JWE, an opaque reference token, an incomplete copy or a malformed transport value. Never invent payload claims for an encrypted or opaque credential.

Different ecosystems have different token contracts. A resource server may accept opaque tokens through introspection rather than public-key JWT verification. Select a debugging workflow that matches your actual architecture instead of assuming every bearer string is a JWT.

JWS: Readable encoded claims with signing protection.

Practical JWT Debugging Workflow for Developers

Begin with an exact copy of a non-production test token from a failing request. Normalize the Authorization header and confirm that the token has the expected segment count. Decode the header and payload to locate algorithm, key ID, issuer, audience, subject, scopes and timestamps. Record which application and environment issued the token, rather than assuming a value found in the payload is trusted.

Next, select a verifier that implements the expected algorithm and has a trustworthy matching key. If the signature fails, check encoding, key rotation, intended key usage and whether the token was modified. If the signature succeeds but the request fails, inspect issuer and audience mismatches, expiry, not-before, required scope, token type and revocation state. Use application logs for the authoritative rejection reason.

When you have two tokens from working and failing flows, compare claim-level differences. Test one variable at a time and retain enough context to reproduce the bug safely. The tool’s audit and educational notes can suggest where to look, but a successful browser-side test is not permission to skip server-side checks.

JWT Decoder FAQs and Search-Friendly Security Knowledge

Questions such as “How do I decode a JWT online?”, “Can I verify RS256 with a public key?” and “Why does a token show expired?” benefit from short direct answers followed by precise context. This page can serve both quick troubleshooting and deeper learning by distinguishing its actual browser features from adjacent concepts such as token introspection, enterprise key management and authorization-policy enforcement.

For SEO, AEO, GEO and LLMO, clear terminology improves usability: describe a JWT decoder as a way to inspect encoded claims, a JWT verifier as a cryptographic signature checker and an expiration analyzer as a display of time claims. These definitions help readers and automated answer systems avoid an unsafe inference that decoding alone authenticates the bearer token.

Internal links to a Hash Generator, Base64 Encoder/Decoder, Password Generator, BCrypt Generator and API Request Tester can guide readers to related tasks without forcing unrelated keywords. Competitor terms such as jwt.io are appropriate only for factual feature comparisons; do not promise superior security, guaranteed rankings or AI recommendations. Keep claims tied to the live page and regularly reassess them as the tool evolves.

JWT Registered Claims and Their Meaning

Interpret claims according to the intended issuer and API policy.

	Meaning	Review action
iss	Issuer	Match the configured trusted issuer.
sub	Subject	Identify the principal without assuming permission.
aud	Audience	Confirm the receiving API or client is intended.
exp	Expiration	Reject at or after the configured expiry boundary.
nbf	Not before	Do not accept before the eligible instant.
iat	Issued at	Review issue time and any maximum-age rule.
jti	JWT ID	Use where needed for replay controls and revocation.

Common JWT Signature Algorithms

Different families require distinct key types and verification configuration.

	Key model	Security consideration
HS256/384/512	Symmetric HMAC secret	Protect a random shared signing and verifying secret.
RS256/384/512	RSA private/public pair	Public verification does not require private signing key.
PS256/384/512	RSA-PSS private/public pair	Pin RSA-PSS algorithms and compatible key parameters.
ES256/384/512	ECDSA private/public pair	Use matching curves and expected algorithm.
EdDSA	Ed25519 signing/verification keys	Check support and pin expected key type.

JWT Expiry and Signature Results

A decoded token should never be accepted on structural checks alone.

	What it indicates	Next step
Readable header/payload	Base64url parsing succeeded	Verify using trusted key and policy.
Valid signature	Cryptographic check succeeded	Validate claims and access rights.
Expired exp	Token has passed expiry	Request an appropriate refreshed token.
Future nbf	Token cannot yet be accepted	Check clock and issuance policy.
Wrong aud	Intended recipient differs	Reject; obtain token for this API.
Wrong iss

JWT Decoder Modes and Export Workflows

Choose the feature appropriate to the task rather than treating all modes as verification.

	What you can do	Important limitation
Decode	Read header and claims	Decoded content is not trusted.
Verify	Check signature with appropriate key	Claims and authorization still require validation.
Generate	Create test JWTs and supported keys	Test signing keys are not automatically trusted by an API.
Compare	Contrast two sets of headers/claims	Changed fields need application-level interpretation.
Bulk	Summarize many tokens	A decoded batch is not necessarily signature-verified.

Frequently asked questions

What is a JWT decoder?

A JWT decoder parses the base64url-encoded header and payload of a JSON Web Token into readable data. It helps inspect claims and structure; it does not by itself verify a token’s authenticity.

Is MyToolSpace JWT Decoder free?

The live page describes the core JWT decoder and security analysis workspace as free and available without sign-up.

How do I decode a JWT online?

Paste a compact token or Bearer authorization value into the tool. Review the parsed header, payload, signature segment and explanations of recognized claims.

Can I paste an Authorization: Bearer token?

Yes. The page documents automatic removal of the Bearer prefix and surrounding whitespace before parsing.

Can I upload a JWT file?

The page documents text or .jwt input workflows and bulk file input. Inspect the imported content before analysis.

Does decoding a JWT verify its signature?

No. Decoding only exposes claims. Open Verify and supply the matching trusted key; then separately validate issuer, audience, expiration and application requirements.

Can I verify HS256 JWTs?

Yes. The tool documents HMAC verification for HS256, HS384 and HS512 with an appropriate shared secret and encoding.

Does it support RS256 verification?

Yes. RS256 and related RSA algorithms are documented. Provide the correct public verification key from a trusted source, such as the appropriate issuer key set.

Can I verify ES256 and EdDSA tokens?

The live page documents ES256/384/512 and EdDSA verification using supported browser cryptographic operations and matching keys.

What is a JWT signature?

It is a cryptographic authentication value calculated over the encoded header and payload. It can detect tampering when verified with the correct key and trusted algorithm policy.

What does exp mean in a JWT?

exp is a NumericDate timestamp after which the token must not be accepted. It is measured in seconds since the Unix epoch.

What are iat and nbf?

iat indicates issue time, and nbf marks the earliest valid time. They serve different purposes from the exp expiration claim.

Why is my JWT expired?

The exp time may be earlier than the current authoritative time. Check time units, clock skew and token issuance policy; do not extend acceptance by ignoring expiry.

What are JWT claims?

Claims are JSON name-value statements in the payload, including registered names such as iss, sub, aud, exp, nbf, iat and jti, and application-defined claims.

What is the iss claim?

iss identifies the issuer; a receiving application must compare it with configured, trusted issuer values rather than trusting any arbitrary token string.

What is aud in a JWT?

aud identifies intended recipients. A service should reject tokens whose audience does not include that service where audience validation is required.

What does sub mean in a token?

sub identifies the principal that the token describes. It does not by itself grant permission to access a particular resource.

What is kid in a JWT header?

kid is a key identifier used to choose among trusted verification keys. It must not be treated as permission to load an arbitrary URL or file.

Is a JWT encrypted?

A typical signed JWS is encoded, not encrypted. Anyone possessing it can read its header and payload; use appropriate JWE or avoid including secrets.

Can this tool decrypt JWE tokens?

The page documents JWE detection and protected-header viewing, not unrestricted decryption of encrypted claims.

What is alg none?

alg none denotes an unsecured JWT. Production validators requiring authenticated tokens must reject this mode.

What is algorithm confusion?

It occurs when a verifier improperly accepts a change in cryptographic algorithm or key type. Explicit algorithm and key-type policy prevents common confusion failures.

Does the tool generate signed JWTs?

Yes. Its Generate mode documents editing claims and signing tokens with provided secrets or keys, along with supported browser-created asymmetric key pairs.

Can I compare two JWT tokens?

Yes. The Compare mode highlights added, removed or changed header fields and payload claims.

Can I inspect several JWTs at once?

Yes. The Bulk analyzer summarizes multiple tokens and documents JSON or CSV export. Bulk decoding alone does not prove each signature valid.

Does JWT Decoder work in my browser?

The page states that decoding, signing and verification run locally using browser cryptography and JavaScript after the page is loaded.

Is it safe to inspect a production JWT?

A bearer token may authorize requests if copied. Prefer low-privilege temporary test credentials, follow organizational policy and avoid unnecessary sharing even when analysis runs locally.

What is an RFC 8725 JWT security audit?

It checks common security concerns informed by JWT best practices, including algorithm problems, time claims and sensitive payload patterns. A score is advisory, not a complete security certification.

What does a JWT 401 Unauthorized error mean?

It means the request lacks acceptable authentication under the service policy. Causes may include a bad signature, expired token, wrong issuer or audience, or header problems; consult server logs.

What is the difference between a 401 and 403 response?

401 concerns missing or unacceptable authentication; 403 commonly indicates the authenticated or identified principal is not allowed to perform the operation. Individual APIs may implement details differently.

What is a JWKS?

A JSON Web Key Set publishes keys, usually public verification keys, for an issuer. A verifier must get and select them from a trusted configured issuer.

Are all OAuth access tokens JWTs?

No. OAuth 2.0 access tokens can be JWTs or opaque strings. Opaque tokens cannot be decoded as JWTs and may require introspection.

Is an ID token the same as an access token?

No. OIDC ID tokens and OAuth access tokens serve different purposes, recipients and validation requirements.

How should I choose between HS256 and RS256?

HS256 uses a shared secret for both signing and verification; RS256 uses a private signing key and a public verification key. Choose according to trust boundaries, library support and key management.

Can this browser tool replace server-side JWT validation?

No. The server must perform trusted signature and claim verification and apply application-specific authorization for every protected request.

How do I export JWT analysis?

The page documents downloadable outputs and JSON/CSV export for bulk analysis. Inspect and secure reports because they may contain sensitive token-derived data.

Can I test weak HMAC secrets?

The page describes a local dictionary-based weak-secret tester. Use it only on tokens you own or are authorized to assess; a no-match result is not proof of a strong key.

Troubleshooting

Problem	Likely cause	What to do
JWT does not decode	The input is malformed, copied incompletely, opaque or not a three-part signed token.	Confirm the original bearer value, count dot-delimited parts and check whether the value is a five-part JWE or opaque token.
Bearer prefix causes parsing confusion	Authorization header text may include extra spaces or surrounding characters.	Paste the header value cleanly and use the tool’s documented Bearer-prefix normalization.
Header decodes but payload fails	A segment may contain invalid base64url data or non-JSON bytes.	Copy the token again from the authorized source and verify all segments were preserved.
Readable JWT appears valid without key	Decoding succeeded but signature verification has not run.	Open Verify, provide the trusted matching key and then check required claims and authorization.
HS256 verification fails	The shared secret, secret encoding or algorithm differs from the issuer.	Check whether the backend expects UTF-8 text, Base64/URL or hex-decoded bytes and use the right secret.
RS256 verification fails	The public key is wrong, old, malformed or not paired with the signing private key.	Find the correct public key from the configured trusted issuer and confirm expected RSA algorithm and kid.
ES256 token cannot verify	Key curve or signature compatibility may not match the algorithm or browser support.	Confirm ES256 with P-256 and import a matching supported key representation.
EdDSA operation is unavailable	The browser or key format may not support the required operation.	Use a modern supported browser and confirm the token uses the documented Ed25519 variant and matching key.
Token shows expired immediately	exp may be in the past or entered with an incorrect time unit.	Check the original NumericDate in Unix seconds, the issuer clock and intended lifetime.
Token says not yet valid	nbf is later than the validating clock’s current time.	Confirm the issuing clock and any narrowly configured clock skew without bypassing security.
401 despite valid signature	Issuer, audience, expiration, token type, scope or revocation could be wrong.	Inspect claims against the API configuration and consult authoritative server rejection logs.
403 despite valid JWT	Identity may be accepted but resource permissions are insufficient.	Check scopes, role mapping and object-level authorization; do not modify token claims as a workaround.
Wrong audience claim	A token intended for one client or API was presented to another.	Request a token from the correct issuer with the intended API audience.
Unexpected issuer	The token came from a different environment or identity provider.	Check staging versus production configuration and allowed issuer values.
kid does not match any key	Issuer keys may have rotated or the key set/configuration is wrong.	Refresh the trusted issuer key set according to your policy and reject unknown keys.
Security score is low	The audit found a potential issue such as alg none, missing exp or sensitive-looking claims.	Review each finding, confirm actual risk and update token issuance or validation rules.
Weak-secret tester finds a match	The HMAC signing key is predictable.	Rotate the key, invalidate affected tokens if warranted and assess exposure under your incident process.
Weak-secret tester finds no match	The tested dictionary did not contain the secret.	Do not infer high entropy; verify secret generation and handling independently.
JWE payload is unreadable	The content is encrypted rather than simply base64url encoded.	Use an authorized JWE-capable decryptor with appropriate keys; the page documents header detection.
Token comparison reports many changes	Refresh or reissuance often changes iat, exp, jti or other claims.	Focus on meaningful audience, scope, subject and issuer changes as well as expected timestamps.
Bulk export includes identifiers	A summary can reveal subject, issuer or other sensitive fields.	Limit distribution, redact identifiers where appropriate and use protected storage.
Generated token is rejected by API	The API does not trust the test signing key or claims.	Configure a dedicated test issuer/key or use legitimate identity-provider test credentials; do not disable production checks.
Incorrect claim time in local display	Timezone formatting may differ from UTC expectations.	Compare NumericDate seconds and UTC instant separately from local presentation.
Unexpected JWT formatting	Header or payload has invalid JSON or altered URL-safe encoding.	Check JSON syntax and base64url encoding, then sign the exact final header and payload.
Missing expiry warning	The test token lacks exp or the environment requires expiry policy.	Add a sensible exp when issuing tokens and enforce it in the receiving service.
Privacy wipe did not remove exports	Downloaded files and clipboard contents are outside the in-page workspace.	Delete unnecessary local copies and clear sensitive clipboard material according to policy.
A pasted token is actually opaque	Not every OAuth bearer credential has readable JWT claims.	Use the issuer’s authorized introspection or troubleshooting mechanism instead of guessing contents.
Server accepts alg none	Production validation is misconfigured to accept unsecured tokens.	Reject none, pin accepted algorithms and retest authentication rejection cases immediately.

Decoded output appears here

Privacy & processing: Runs in your browser

How to use JWT Decoder

Paste a JWT or Import a Token

Inspect Claims, Expiration and Security

Verify, Compare or Export

Go ad-free & unlock more

Go ad-free & unlock more

Key features

Instant JWT Header and Payload Inspection

Real Cryptographic Signature Checks

Expiration and Timestamp Timeline

Security Audit and Risk Flags

JWT Generation and Key Pairs

Compare Two JSON Web Tokens

Bulk JWT Analysis

Browser-First Token Processing

Developer Verification Snippets

JWT Education and Standards Context

What Is a JWT Decoder, and What Does MyToolSpace Inspect?

JWT Structure Explained: Header, Payload and Signature

Decode vs Verify vs Validate: Three Different JWT Checks

JWT Claims Guide: exp, iat, nbf, iss, aud, sub and jti

JWT Signature Algorithms: HS256, RS256, PS256, ES256 and EdDSA

Check JWT Expiration and Debug 401 Unauthorized Errors

JWT Security Audit and RFC 8725 Best Practices

Weak HMAC Secret Testing and Defensive Key Hygiene

Generate Signed JWTs and Browser-Based Test Key Pairs

Compare JWTs and Analyze Many Tokens in Bulk

JWT Privacy: Browser Processing, Sensitive Tokens and Wipe Controls

JWT in OAuth 2.0, OpenID Connect and JWKS-Based APIs

JWS vs JWE vs Opaque Tokens: What Can Be Decoded?

Practical JWT Debugging Workflow for Developers

JWT Decoder FAQs and Search-Friendly Security Knowledge

JWT Registered Claims and Their Meaning

Common JWT Signature Algorithms

JWT Expiry and Signature Results

JWT Decoder Modes and Export Workflows

Common use cases

Backend API Developers

Application Security Reviewers

OAuth and OIDC Integrators

Support and Incident Engineers

Students and Security Learners

QA and Test Automation Teams

Platform Migration Teams

Security Audit Coordinators

Full-Stack Web Developers

Practical tips

Never Trust Decode Alone

Pin Your Accepted Algorithms

Validate Audience and Issuer

Use Test Tokens for Debugging

Keep Payloads Non-Secret

Match Key Formats Exactly

Check NumericDate Units

Treat kid as Untrusted Input

Keep Access Tokens Short-Lived

Rotate Exposed HMAC Keys

Secure Generated Private Keys

Compare Tokens Carefully

Protect Exported Reports

Use Privacy Wipe After Testing

Enforce Authorization on the Server

Frequently asked questions

Troubleshooting