Developer tools · JWT decoder
Decode vs Verify: What a JWT Signature Proves and Why Decoders Skip It
· How it works
jwt security cryptography
Decoding needs no key; verifying needs the right one. This post explains what the signature covers, how HMAC and asymmetric verification differ, and why a decode-only tool is honest about proving nothing.
It decoded fine, so it must be valid — the assumption that leads to accepting forged tokens
A token can decode perfectly after an attacker writes a new payload and attaches arbitrary text as the third segment. Base64url and JSON parsing are public transformations; neither checks who assembled the string. “The claims appeared on screen” is therefore not evidence that the issuer created or approved them.
ToolAcre reinforces this boundary in several places. The result always carries `signatureVerified: false`, the UI repeats an unverified-claims alert beside output, and tests assert there is no `valid` or `verify` surface. That is deliberate honesty, not a missing convenience feature.
What the signature covers — the exact bytes of the encoded header and payload, joined by a dot
For compact JWS, the signing input is the encoded protected-header segment, a literal dot and the encoded payload segment. Verification concerns those exact encoded bytes, not freshly pretty-printed JSON. Reordering properties or changing whitespace can create different bytes even when a human sees equivalent objects.
The third segment carries encoded signature or MAC bytes produced over that input. ToolAcre preserves the raw segment and may report its byte length, but it never runs a cryptographic check. Measuring data shape cannot establish that the expected key created it or that the first two segments remained unchanged.
HMAC versus asymmetric — a shared secret that anyone who can verify can also forge, versus a public key that can only verify
With HMAC, a shared secret supports both creating and checking the MAC. A party able to verify with that secret can also mint another token, so secret distribution defines the trust boundary. ToolAcre’s notes make this consequence explicit for its recognised HS algorithm labels.
Asymmetric signatures separate a private signing capability from public verification material. Possessing a public key can support checking without granting signing authority. This distinction does not make a header-declared asymmetric label trustworthy: the verifier must already know which algorithm and issuer key are acceptable.
Where the key comes from — configuration for shared secrets, a JWKS endpoint for public keys, matched by kid
Shared secrets should come from protected service configuration, not token text. Public verification keys may come from a trusted issuer relationship and controlled key set. A `kid` can help select within that set, but it must not turn arbitrary untrusted header content into a file, database or network lookup.
ToolAcre has no issuer configuration and requests no key, so verification would be impossible to perform responsibly there. A generic web page cannot infer which organization you trust, which audience you serve or which algorithms your application permits. Those are application policy inputs, not properties discoverable by decoding.
Why decoding needs no key — base64url is an encoding, not encryption, so anyone can read the claims
No key is needed to decode because base64url is reversible encoding rather than encryption. The header and payload are meant to travel with the token and can be recovered by any holder. This enables useful inspection, but also means confidential information should not be hidden behind the visual noise of encoded characters.
JSON parsing adds structure only. It can tell you that `roles` is an array or `exp` is a number, not that either value is authentic. ToolAcre renders structured values as text and registered descriptions as documentation while leaving authorization to the system that can verify and enforce policy.
Worked example — a token with one payload character changed still decodes perfectly; only verification notices
Start with a synthetic token whose payload says `{"sub":"demo","role":"reader"}`. Change one encoded payload character so the bytes still form valid JSON, perhaps producing a different role. Both versions can split, decode and pretty-print. The decode path has no reason to reject the changed version.
A correctly configured verifier recomputes or checks the cryptographic result over the changed signing input and rejects the mismatch. This comparison demonstrates the precise boundary: decoder success covers syntax, while verifier success can establish integrity relative to a trusted key and permitted algorithm before claim policy is evaluated.
What this does not cover — the ToolAcre JWT decoder never verifies the signature, by design; nothing it shows proves a token is genuine
ToolAcre never verifies the signature. An empty segment receives a warning, malformed signature encoding receives another, and measurable bytes are reported as present but not verified. None of these branches produce a genuine-token verdict. The implementation has no hidden key acquisition or algorithm execution path.
Even successful cryptographic verification would not automatically authorize an action. The consuming service still needs issuer, audience, time and application-specific checks. This article stops before library configuration because support and defaults vary; consult the exact verifier and version used by your service.
Takeaway: decode to inspect, verify to trust — use the ToolAcre JWT decoder for the first and a server-side library with the right key for the second
Decode to inspect and verify before trust. Use the browser tool for an expired or synthetic token when you need to see header fields, payload values, time conversions and structural warnings. Never let that readable output flow directly into an access decision.
Move consequential work to a trusted verifier with independently supplied key material, pinned algorithms and service policy. Only that path can test authenticity and integrity, and only subsequent claim checks can decide authorization. A decoder’s refusal to blur those jobs is a security feature.