Securityversion v1.0.0
JWT Inspector
Read what is actually inside a token: the JOSE header, the claims set, and where exp and nbf sit relative to now. Pasting happens in this tab and nothing is sent anywhere.
This is a decoder, not a debugger and not a verifier. The three parts of a JWT are base64url, not encryption, so anyone can rewrite a claim and re-encode it — and it will still decode here perfectly. Signatures are never checked, on any surface, and every response says so.
nothing pasted yet · decoded in this tab · nothing sent, stored or remembered
This decodes. It does NOT verify.
The three parts of a JWT are base64url, not encryption. Anyone holding this token can change a claim, re-encode it, and it will still decode cleanly here. Reading it tells you what it says, never whether it is genuine.
To actually check it, verify the signature against the issuer's key — locally, with your key, on your machine:
printf '%s' "$JWT" | step crypto jwt verify --key issuer.pem --iss … --aud …Privacy
A JWT is usually a live credential for a named user, right now, in production. Possession is authorisation, so this page treats it that way.
- This page decodes in your browser tab. There is no network request in it at all — no upload, no beacon, no error reporting, no prefetch.
- The token is never in a URL, by construction. There is no
?token=on the page or the endpoint, because query strings are copied into browser history, proxy logs and CDN access logs. - Nothing is persisted: no browser storage, no cookies, no history entry, no “recent tokens” list, no autofill. Reloading this page loses the token, and that is deliberate.
From the command line
The same URL answers a POST with the value alone and exactly one newline — ?out=payload emits the claims verbatim, so | jq -r .sub works with nothing to strip first.
printf '%s' "$JWT" | curl -fsS --data-binary @- 'https://tools.primeforge.app/jwt'printf '%s' "$JWT" | curl -fsS --data-binary @- 'https://tools.primeforge.app/jwt?out=expiry'The endpoint sends your token to our server. This page does not. That is a fair trade for a token from a staging environment and a bad one for a production access token — you are entitled to know which you are making. The server reads the body in memory, answers, and keeps nothing; request paths are logged, bodies never are.
Every snippet uses "$JWT" rather than a pasted token on purpose: a token typed literally into a shell lands in ~/.zsh_history and stays there. ?out=expiry always answers HTTP 200 — even for an expired token — so curl -f can never be wired up as an authorisation gate.