JWT Inspector
JWT Inspector decodes a token, lays its registered claims out in a readable table, and tells you at a glance whether the token is expired or not yet valid. Timestamp claims like exp, iat and nbf are shown both raw and as readable UTC dates.
Add your secret and it verifies the HS256 signature locally, confirming the token is authentic and untampered. All decoding and verification run in your browser — nothing is sent to a server.
Header
{
"alg": "HS256",
"typ": "JWT"
}Payload
{
"sub": "1234567890",
"name": "Jane Doe",
"iat": 1516239022
}Claims
| Claim | Name | Value | Readable (UTC) |
|---|---|---|---|
sub | Subject | 1234567890 | — |
name | — | Jane Doe | — |
iat | Issued at | 1516239022 | Thu, 18 Jan 2018 01:30:22 GMT |
Decoding and verification run entirely in your browser. Signature verification supports the HS256 algorithm only.
How to use JWT Inspector
- 1
Paste the token
Drop a JWT into the input. The header and payload decode instantly into formatted JSON, and a status badge shows the validity window.
- 2
Review the claims
The claims table names each registered claim and renders exp, iat and nbf as both Unix timestamps and human-readable UTC dates.
- 3
Verify the signature
Optionally enter the HS256 secret. The inspector re-signs the token locally and shows whether the signature is valid or invalid.
Reading registered claims
JWTs use a small set of registered claims with standard meanings. iss identifies the issuer, sub the subject (often the user ID), and aud the intended audience. The time claims — iat (issued at), nbf (not before) and exp (expiration) — are Unix timestamps in seconds, which are hard to read at a glance. The inspector converts them to UTC dates so you can immediately see when a token was created and when it stops being valid.
From exp and nbf, the inspector computes a live status: a token is expired once the current time passes exp, not yet valid before nbf, and otherwise within its validity window. This makes it easy to diagnose the classic "token rejected" problem, which is usually an expired token or a clock-skew issue between systems.
Verifying an HS256 signature
Decoding tells you what a token says; verification tells you whether to believe it. To verify an HS256 token, the inspector recomputes the HMAC-SHA-256 of the header-and-payload signing input using the secret you provide, then compares it to the signature in the token. A match proves the token was signed with that secret and hasn't been altered.
Verification only works for HS256, the symmetric HMAC algorithm. Tokens signed with asymmetric algorithms like RS256 or ES256 require the issuer's public key and a different process, so the inspector clearly states when it cannot verify a given algorithm. Verifying with the wrong secret — or against a tampered token — returns an invalid result.
Frequently asked questions
- How does it decide if a token is expired?
- It compares the current time to the exp claim, and to nbf for not-yet-valid tokens. The result is shown as a status badge and recomputed each time you load a token.
- Which algorithms can it verify?
- Signature verification supports HS256 only. For other algorithms it decodes the token and shows the claims but notes that it can't verify the signature.
- Do I need a secret to use it?
- No. The secret is optional — without it you still get full decoding, humanized claims and expiry status. The secret only enables signature verification.
- Is anything sent to a server?
- No. Decoding and HS256 verification both run in your browser using the Web Crypto API; the token and secret never leave the page.
Last updated: