01
Keep automatic reading distinct from verification
Automatic decoding waits 350 ms after edits. Turn it off to use Decode or Ctrl/Cmd+Enter. The switch never triggers signature verification or test-token generation.
Public-key inspection
JWT debuggerwith separate signature and claim checks
Read a token first, then explicitly decide which public key and algorithm to trust.
JWT debugger
JWT token
Token and keys stay in this page’s memory. No remote key requests or input storage.
Decoded JSON and report
Unverified: decoding does not validate a token.
Signature and claim settings
Choose the expected algorithm yourself. A matching signature does not establish issuer identity, permission, revocation status or overall token validity.
User-supplied public key
One public JWK or SPKI PEM PUBLIC KEY. RS256 requires RSA 2048–8192 bits; ES256 requires P-256. Private keys and remote JWKS are not accepted.
exp, nbf and iat checks are independent of signature. Future iat is flagged by this debugger policy. Missing times remain missing; empty issuer/audience means unchecked. UTC display uses millisecond precision; the original fraction stays in the report.
Token: 100,000 characters; key: 20,000; test claims: 50,000. Strict base64url, UTF-8 and object JSON only. Duplicate keys and numbers that change on conversion are rejected.
Test token generator
Paste a compact JWT to begin.
Use this JWT debugger to investigate a rejected API request: inspect the header and claims, compare the reported issuer and audience, and see the time fields as UTC dates. The initial result is decoded data with an unverified signature.
A JWT decoder reads the first two base64url segments without a key. Signature verification requires an explicit algorithm and a public key; an expiration check answers a different question. These results remain separate throughout the report.
Why use this JWT debugger?
Readability without an implied trust decision
This JWT debugger keeps the signature status separate from the time checks. An expired token may still have a matching signature; a readable payload may have no trustworthy signature at all. This distinction helps explain why an API rejects apparently normal JSON.
Practice with a separate test draft
Enable the JWT encoder for tests to create a temporary local key pair. Generation produces a preview; applying it replaces the main token and public key together. One undo restores the previous input and result, so a test does not silently overwrite your investigation.
Choose what each check should mean
02
Supply expectations from outside the token
Choose RS256 or ES256 yourself and paste a public JWK or SPKI PUBLIC KEY PEM. Enter an expected issuer or audience when needed. Header key references never select a trusted key.
03
Check the time reference before exporting
An empty reference uses the current time for each run. A supplied Unix-second value makes a check reproducible. The current-time action previews a replacement; changed inputs disable export until results refresh.
Inspect the reasons an API might reject a token
Readable header and claims
Strict decoding shows the JSON objects and signature information. The report distinguishes the declared algorithm from your expected algorithm; neither a kid nor a URL establishes trust.
Explicit public-key comparison
JWT signature verification accepts RS256 with RSA 2048–8192 bits or ES256 with P-256. A mismatch is reported separately from an invalid key, an unsupported algorithm or malformed input.
A reproducible expiration check
Use the JWT expiration checker for exp, nbf and iat with a reference time and 0–86400 seconds of tolerance. Future iat is flagged by this debugger policy; absent fields stay missing.
Claims beyond the clock
Compare iss exactly and check whether aud equals or contains the expected audience. Empty expectations remain unchecked. A signature match cannot grant access or establish revocation status.
Accepted input and deliberate boundaries
- Three compact segments only
- Provide the raw token without a Bearer prefix, surrounding spaces or padding. Five-part JWE is not decoded or decrypted. none may be inspected with an empty signature but is never verified.
- Strict JSON and number handling
- Header and claims must be UTF-8 JSON objects. Duplicate member names, isolated surrogates and noncanonical base64url fail. Numbers that silently change during conversion are rejected; representable fractions are allowed.
- Only public verification material
- Use one public JWK or a complete SPKI PUBLIC KEY PEM. Private and symmetric key material is rejected. A JWK with conflicting alg, use or key_ops also fails; this is not a key-format converter.
- No remote keys or extension verification
- jku, x5u, kid, embedded jwk and x5c are displayed as untrusted metadata. Nothing is fetched from them. Tokens containing crit, b64 or zip are not verified by this implementation.
- Measured limits and clock behavior
- Limits are 100,000 token characters, 20,000 key characters and 50,000 test-claim characters. Times outside the supported Date range are invalid. UTC display has millisecond precision; the original fraction stays in the report. Generated tokens must also fit the token limit; oversized results fail without truncation.
- Tests do not become authentication
- The independent generator starts disabled and uses temporary keys only after Generate. Applying its preview does not verify the result. Signature, issuer, audience and time checks never replace application authorization or revocation checks.
JWT debugger questions
Can I verify a JWT signature here?
Yes, after explicitly choosing RS256 or ES256 and supplying the corresponding public JWK or SPKI PEM key. The signature result describes that key comparison only; inspect the separate time, issuer and audience results as well.
Why does my JWT show as expired?
The exp value is in Unix seconds. At the reference time, the check fails when the time minus tolerance reaches exp. A wrong reference or a device clock that is ahead can explain an unexpected result.
Is a JWT encrypted?
A signed compact JWT exposes its header and claims through base64url encoding. That encoding provides no confidentiality. The signature protects integrity when verified with the expected key; it does not hide the payload.
Does it support encrypted JWTs (JWE)?
No. This workbench handles three-part compact tokens and rejects five-part JWE. Use the issuer’s appropriate decryption tooling for encrypted payloads; no decryption key is requested here.
Can it verify RSA or ECDSA signatures?
Yes: RS256 with RSA public keys of 2048–8192 bits, and ES256 with P-256. Other RSA and ECDSA variants are outside this verifier’s scope, although their ordinary header and claims may still decode.
Something unexpected in the report?
Return to your inspection
Use the JWT debugger with the expected algorithm, a known public key and a deliberate time reference; export only the report for the current inputs.