Token will not decode
confirm three dot-separated Base64URL segments and valid JSON in header/payload.
JWT Debugger
Inspect a JSON Web Token and keep decoding, signature verification and claim-policy validation as three separate concepts.
Developer & Text ToolsRead the full guideDirect answer
A JWT debugger Base64URL-decodes the header and payload and can verify or create a signature for supported algorithms. The current AppKiro UI names HS256, HS384 and HS512 with an HMAC secret; decoding alone does not prove authenticity, and signature verification alone does not validate issuer, audience, expiry or application policy.
Verify signature
How to use it
Enter the source data: Paste a disposable JWT to inspect, or enter synthetic header/payload JSON for signing. Confirm the token has exactly three compact-serialization segments when a signed JWT is expected.
Choose the relevant settings: Choose the named HMAC algorithm and provide only a test secret. Never accept the token header algorithm blindly; the verifier must enforce the user/application-selected allowlist.
Review and verify the result: Review decoded claims, signature status and claim-policy status separately. Check exp, nbf, iss, aud and clock assumptions in the application that will consume the token.
Key capabilities
- Decodes JWT header and payload segments.
- Separates decode from verify workflows.
- Names HS256, HS384 and HS512 HMAC options in the current UI.
- Creates a compact JWT from test header/payload and HMAC secret.
- Provides structured copyable output with required security warnings.
Best use cases
- Inspect synthetic JWT structure during development.
- Verify an HMAC signature against a known test vector.
- Demonstrate why decoded claims are not trusted until verification and policy checks pass.
Limits and safety notes
- JWT payloads are encoded, not encrypted. A valid HMAC signature means the signer knew the shared secret; it does not mean every claim is acceptable. Algorithm confusion, weak secrets, ignored expiry/audience/issuer and production-token leakage are serious risks.
- Use only synthetic test data. Do not paste production tokens, passwords, seed phrases or signing secrets into this page until its local-only behavior has been independently verified.
- The current tool decodes three JWT segments and can sign or verify HS256, HS384 and HS512 with a shared secret. It also exposes alg=none for debugging; it does not verify asymmetric algorithms, issuer, audience or token expiry.
Troubleshooting
Signature fails
verify exact token bytes, algorithm, secret encoding and that no whitespace was changed.
Signature passes but token is rejected
check exp, nbf, iss, aud, clock skew and application-specific authorization policy.
Frequently asked questions
Is decoding a JWT the same as verifying it?
No. Decoding only reads Base64URL-encoded JSON. Verification recomputes and checks the signature with an allowed algorithm and key.
Which algorithms are supported?
The rendered UI names HS256, HS384 and HS512. Do not claim support for RS, ES, PS or none until runtime behavior and allowlists are verified.
Can I paste a production token or secret?
The core transformation runs in the current browser component. Browser extensions, clipboard history, downloaded files and site-wide diagnostics remain separate exposure points, so never enter production secrets unless you have reviewed the complete environment.
Is it safe and private?
Short answer: Use only synthetic test data. Do not paste production tokens, passwords, seed phrases or signing secrets into this page until its local-only behavior has been independently verified.
Does it work on mobile?
The layout adapts to narrow screens. File selection, camera access, clipboard actions and downloads still depend on the permissions and capabilities of the mobile browser.
Related tools
Use the tool
Use a disposable token, enforce an explicit algorithm and treat decode, signature verification and claim validation as separate result states.