How to inspect a JWT locally on Mac.

Start by decoding the token structure

A JSON Web Token has three dot-separated parts: a header, a payload, and a signature. The header identifies the signing algorithm, while the payload contains claims such as the issuer, audience, subject, issued-at time, and expiry time.

Decoding lets you read those first two parts. It does not prove that a token is genuine, trusted, or safe to use. Treat decoded data as information to inspect, not as verified identity.

Check the claims that explain common failures

When an API rejects a token, start with exp, nbf, and iat. An expired token, a token that is not valid yet, or a clock mismatch can look like an authentication problem even when the token format is correct.

Then check iss and aud against the values your service expects. Finally, look at sub, scopes, roles, or custom claims to confirm that the token describes the user or permission you intended to test.

Verify only when you have the right key

Signature verification answers a different question from decoding: whether the token was signed by someone who holds the expected key. For an HS256 token, you can verify the signature locally with the shared secret your system uses.

Do not paste a production signing secret into a public decoder. A local tool keeps both the token and the secret on your Mac, which is especially useful while debugging OAuth flows, webhooks, and test environments.

Keep the debugging workflow close to your code

The fastest JWT workflow is usually small: copy a token, inspect the claims, check its expiry, and return to the editor or terminal. Keeping that flow in the menu bar avoids browser tabs and makes it easier to handle sensitive development data deliberately.