A JWT is three base64url-encoded segments joined by dots: a header (which algorithm signed it), a payload (the claims, things like sub, exp, iat), and a signature over the first two segments. Decoding just base64url-decodes the header and payload, which anyone can do without any secret, that's why this tool also has a separate verify step, which recomputes the signature using either an HMAC secret (HS256/384/512) or an RSA public key (RS256/384/512) and checks it byte-for-byte against the token's third segment.
No. Decoding just reads the base64url-encoded header and payload, it works on any well-formed token, valid signature or not, since that data isn't encrypted. Verifying is the separate step where the tool recomputes the signature with a secret or public key and confirms it matches; only then do you know the token wasn't tampered with.
HS256 is symmetric, the same secret string both signs and verifies the token, so whoever can verify it can also forge one. RS256 is asymmetric, a private key signs, and a separate public key verifies, so a service can safely hand out its public key to let others verify tokens without ever being able to issue new ones themselves.
Not for anything security-sensitive. Since the payload is only base64url-encoded, not encrypted, anyone can edit claims like a user ID or role and re-encode them, the signature is what proves the claims haven't been altered since a trusted party issued the token. Always verify before relying on a claim's value.