How is the result calculated?
Reading an ID token from your logs
Your service's access logs contain a token like the RFC 7515 example — a header declaring HS256, a payload with a subject, a name, and an issue time, and a signature segment. Decode it to read the claims as the server would, then paste the shared secret to confirm the signature actually matches — a tampered sub or an expired iat shows up as Signature invalid.
Example input and output | Input | Value |
| token | eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c |
| secret | your-256-bit-secret |
| Result | {"sub":"1234567890","name":"John Doe","iat":1516239022} — Signature valid |
What is the formula and its assumptions?
JWT compact serialization
JWT = base64url(header) + "." + base64url(payload) + "." + base64url(signature)
Formula terms | Symbol | Meaning |
header | the JSON header: alg, typ, and often kid — the signing algorithm and key id |
payload | the JSON claims: registered (sub, iat, exp, nbf, iss, aud) plus custom claims |
base64url | base64 with URL-safe characters (- and _) and no padding |
RFC 7519 §3.1. The tool decodes segments with base64url and pretty-prints the JSON; it never re-orders or interprets claims.
HMAC signature verification
valid = verify(HMAC-{SHA-256|384|512}(secret), base64url(header.payload), signature)
Formula terms | Symbol | Meaning |
secret | the shared HMAC secret you paste — used only in the browser, never sent |
base64url(header.payload) | the signing input: the first two segments exactly as carried in the token |
signature | the third segment, decoded to the raw MAC bytes |
crypto.subtle.verify performs a constant-time comparison, so a mismatch can never leak timing. Asymmetric algorithms need the signer's public key and are reported as unverifiable locally.
What are the most common mistakes?
- Trusting a token because it decodes — decoding shows the claims, not who signed them; only a valid signature check proves origin, and only for HMAC tokens with the right secret.
- Assuming alg=none tokens were "fine to decode" — they are unsigned and must be rejected by any library that accepts them.
- Pasting production tokens into online decoders that upload them — this tool is fully local; many web services keep your token and claims.
What are the assumptions and limitations?
- Signature verification covers HMAC (HS256/384/512) only — asymmetric tokens are reported as unverifiable locally.
- Claims are displayed raw (epoch seconds for exp/iat/nbf); the tool does not convert them.
- Opaque access tokens are not JWTs and cannot be decoded.
Where do the numbers come from?
Last reviewed August 12, 2026 · Version 1.0.0 · Toolivaro does not guarantee external content.
Frequently asked questions
Is my token uploaded anywhere?
No. Decoding and signature verification run entirely in your browser with WebCrypto — no network request is made with your token or secret. That makes the tool safe even for production tokens carrying real user claims.
Why can't you verify RS256 tokens?
RS256 and the other asymmetric families are verified with the signer's public key, which lives at the issuer's JWKS endpoint — a client-side tool has no trustworthy way to fetch and trust that key for you. The decoder reports such tokens as unverifiable locally instead of faking a result. HMAC (HS256/384/512) tokens only need the shared secret, so those are checked when you provide it.
What does it mean when a token says alg=none?
alg=none declares the token was not signed at all. Libraries that accept none are the source of infamous authentication bypasses. The decoder flags such tokens as unsecured, with no signature segment to check.
Why are exp and iat shown as raw numbers?
Because that is how the token carries them — NumericDate epoch seconds per RFC 7519. The tool does not silently convert or interpret claims: silent conversion is where decoders lie, and the raw value is the ground truth the server sees.
Can this tool decode OAuth 2.0 access tokens?
Only if they are JWTs. Many providers (Okta, Auth0, Azure AD) issue JWT access tokens, and those decode here. Opaque tokens — random strings that are just identifiers — have no JSON inside and are not JWTs; no decoder can turn those into claims.
Part of Password, hashing, and security tools
Found a mistake or have a correction? Report it — we review every correction.
Reviewed by the Toolivaro editorial team per our methodology Methodology · Editorial policy