JWT Debugger
Decode, inspect, and verify JSON Web Tokens — 100% in your browser
Paste your JWT
Verify signature
Verification happens entirely in your browser using the Web Crypto API — secrets and keys never leave your machine.
Need this on-premise or behind your firewall?
We ship a self-hosted enterprise edition of our identity tools (SAML, OIDC, JWT) — air-gapped, auditable, no data leaves your network. Contact us for details.
About the JWT
A JSON Web Token carries authentication data between services in a compact, URL-safe format. When debugging auth flows, you need to see inside the token — which algorithm signed it, what claims were granted, when it expires — and critically, whether the signature actually validates against your secret or public key.
This debugger decodes the header, payload, and signature; displays registered claims (iss, sub, aud, exp, iat, nbf) with human-readable timestamps; shows expiry status at a glance; and verifies signatures using the browser native Web Crypto API. Everything runs client-side — tokens and secrets never leave your machine.
How to use
- Paste your JWT (the three dot-separated base64url parts).
- The header, payload, and claims decode instantly.
- Check the expiry banner to see if the token is still valid.
- Enter your HMAC secret or RSA public key and click Verify.
Frequently Asked Questions
How do I verify an HS256 JWT signature? ▾
Paste the JWT, then enter the shared secret in the verification section and click Verify. The tool uses the browser Web Crypto API to compute the HMAC-SHA256 and compare it with the signature segment of the token.
How do I verify an RS256 JWT with a public key? ▾
Paste the JWT, then paste the RSA public key in PEM format (the block starting with -----BEGIN PUBLIC KEY-----). The tool imports the key via Web Crypto and verifies the RSASSA-PKCS1-v1_5 signature.
What is the difference between HS256 and RS256? ▾
HS256 uses a shared secret (symmetric) — both signer and verifier know the same secret. RS256 uses an RSA key pair (asymmetric) — the signer holds the private key, and the verifier only needs the public key. RS256 is standard for production services.
Can this tool create or sign JWTs? ▾
It currently decodes and verifies. Signing requires the private key or secret on the signing side, which is typically done in your backend code — not in a browser tool.
Is it safe to paste a production token here? ▾
Yes. Decoding and verification happen entirely in your browser using the Web Crypto API. No token, secret, or key is transmitted to any server. That said, JWTs are bearer credentials — treat them carefully regardless of the tool.
Is it safe to paste a production JWT into this debugger? ▾
Yes — decoding and signature checks run entirely in your browser; the token is never sent to a server. That is precisely the difference from online debuggers that POST your token to their backend.
What should I check when a JWT fails verification? ▾
Confirm the algorithm matches what your backend expects (alg confusion is a classic exploit), the exp/nbf times are valid for the current clock, and for HS256 that the shared secret is exact — one trailing newline breaks HMACs.
Can a JWT be revoked before its expiry? ▾
Not by the token itself — JWTs are stateless. Expired-only revocation is why access tokens should be short-lived, with revocation handled by a server-side denylist or refresh-token rotation.