The token never touches a server. Paste it here and see the header, payload, expiry, and signature — decoded and verified entirely inside your browser using the Web Crypto API.
client-side · zero network calls · no telemetry · no login
// paste your jwt
Paste. Inspect.
Paste a JWT below. All decoding happens in your browser — the token never leaves your machine.
algorithm
—
issued at
—
expiry
—
status
—
01 · header
02 · payload
03 · signature
// how to verify zero network calls
Open DevTools (F12 or Cmd+Option+I), click the Network tab, then reload this page and paste your JWT. You will see requests for fonts and the initial page load — and nothing else. No requests fire when you decode. jwt.io sends your token to a remote endpoint during signature verification; this tool processes everything in crypto.subtle, which never touches the network. If you see an outbound request to any domain other than fonts.googleapis.com or fonts.gstatic.com after the page loads, that is a bug — report it to [email protected].
// jwt.io sends your token to a server
jwt.io sends your token to a server. That server is not yours.
jwt.io is the default. The "Verify Signature" feature fires a POST request with your token in the body — to Auth0's infrastructure, not yours. Production tokens carry user IDs, email addresses, scopes, and session references. When you paste one at 3am during an auth incident, it lands in someone else's log.
This tool uses the browser's built-in crypto.subtle API for signature verification. Everything stays in your browser tab. Close the tab and it's gone.
// frequently asked questions
Common questions about JWT Inspector
Does this tool send my JWT to a server?
No. Every decode and verification operation runs inside your browser using the Web Crypto API. The token you paste is never transmitted over the network — not to Septim Labs, not to any third party. You can disconnect from the internet and the tool still works.
How is this different from jwt.io?
jwt.io is maintained by Auth0 (Okta). For RS256 and ES256 tokens, jwt.io fetches the public key from a remote JWKS endpoint, which means a network request is made during verification. This tool uses the key material you paste directly — no outbound requests. If your token contains production credentials or internal claims, this distinction matters.
Which signing algorithms does this inspector support?
HS256, HS384, HS512 (symmetric HMAC), RS256, RS384, RS512 (RSA), and ES256, ES384, ES512 (ECDSA). All verified against RFC 7518 algorithm identifiers.
Can I verify a JWT with an expired signature?
Yes — the inspector flags expiry in the exp claim but still decodes and displays all header and payload fields. This is useful for debugging tokens from logs where expiry is expected.
Is this safe to use with production tokens?
The tool is client-side only, so no data leaves your machine. That said, treat production tokens as secrets regardless of tooling. For routine debugging use a test environment token; for production incident triage, this is the safer choice compared to any server-side tool.
// if you paste secrets into tools that phone home
If you're decoding JWTs here, API keys and .env values are in the mix too — and those usually live in Slack, a Notion doc, or a shared spreadsheet someone forgot to revoke. Septim Vault keeps secrets AES-256-GCM encrypted in the browser, processed entirely client-side. Nothing leaves your device. $29 once.