togotools.top technical reference
Technical reference
Decode JWT headers and payloads locally, inspect exp, nbf, and iat NumericDate claims, and verify HS256, HS384, or HS512 signatures with a shared secret. Decoding is not trust; verification requires a trusted key.
What it checks
- Parses the three JWT segments: header, payload, and signature.
- Converts exp, nbf, and iat into readable dates and marks expired or not-yet-active states.
- Verifies HS256, HS384, and HS512 HMAC signatures with the supplied shared secret.
- Tokens and secrets stay in the browser; the page does not contact the token issuer.
Example: inspect an expiration claim
exp is a Unix timestamp in seconds and marks the expiration time; nbf marks the start time. Real authentication also depends on clock skew, revocation, and authorization checks.
{
"sub": "user-123",
"iat": 1767225600,
"exp": 1767312000
}Security boundary
A JWT payload is usually Base64URL encoded, not encrypted. Anyone holding the token can read non-sensitive claims, so do not place passwords, private keys, or unnecessary personal data in the payload.
- A signature only matters when the algorithm, trusted key, and server verification rules are correct.
- Do not trust a token based only on its alg field or decoded claims.
- Clear production tokens after use on shared or public computers.
Frequently asked questions
Does decoding a JWT prove it is valid?
No. Decoding reads claims but cannot prove the signature, revocation state, or current authorization.
Why is exp such a large number?
JWT NumericDate uses Unix time in seconds since 1970, rather than a formatted date or millisecond timestamp.