A signed JWT is header.payload.signature, each part base64url without padding: the header names the algorithm (alg), key (kid) and type (typ), and the payload holds claims such as iss, sub, aud, exp, nbf, iat and jti (RFC 7519 §4.1) plus application claims. Encrypted JWTs have five parts. The payload of a signed JWT is readable by anyone who has the token: signing protects integrity, not confidentiality.
Verification has two halves: the signature, with an algorithm and key the verifier chose in advance, and then the claims — issuer, audience, expiry with a small clock-skew allowance, and the token type, so that an ID token is not accepted where an access token is expected. RFC 8725 (JWT Best Current Practices) lists these rules; most JWT vulnerabilities come from skipping one of them.
Algorithm choice is a trade-off covered in ES256 vs RS256 and HS256 vs RS256. The JWT debugger decodes and verifies tokens locally.