Anyone can Base64URL-encode a header and payload. Their readability proves only that bytes can be decoded, not who created them or whether they were changed. A signature is meaningful only after a verifier selects an allowed algorithm and trusted key under the receiving application's policy.
Four separate questions
Parsing asks whether the syntax is well formed. Signature verification asks whether protected bytes match a trusted key. Claim validation asks whether issuer, audience and time constraints satisfy policy. Authorization asks whether this subject may perform this action. Passing one layer never implies passing the next.
Do not trust alg from the token
The header's alg value is untrusted input, not permission to choose any verifier. The service must have its own allow-list and reject none, algorithm substitution and key-type confusion unless a deliberately reviewed protocol requires a specific case.
Verification checklist
After inspecting structure, verify the compact token with a maintained JOSE library in the service that receives it. Pin the allowed algorithm; select the trusted key by reviewed policy; validate the signature before trusting claims; then enforce issuer, audience, subject, expiry, not-before, clock tolerance and application-specific requirements. Reject unexpected critical headers and duplicate data before authorization. JWTLens deliberately performs none of these trust decisions.