JWT Decoder: Inspect and Debug JSON Web Tokens Online

If you've ever built a login flow, called a protected API, or integrated with an OAuth provider, you've worked with JSON Web Tokens. JWTs are the de facto standard for transmitting authentication and authorization data between services. They show up in headers, cookies, URL parameters, and local storage across virtually every modern web application.

But here's the thing: JWTs are opaque by design. They look like three random strings separated by dots. When something goes wrong — a 401 error, a permission denied, a token that "should still be valid" — you need a way to crack them open and see what's actually inside. That's where a JWT decoder comes in.

What Is a JWT?

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe token format defined in RFC 7519. It's used everywhere: OAuth 2.0 access tokens, OpenID Connect ID tokens, API authentication, single sign-on sessions, and even some payment systems. If your app talks to any cloud service — AWS, Firebase, Auth0, Supabase, Clerk — you're already dealing with JWTs whether you realize it or not.

JWTs are popular because they're stateless. The server doesn't need to look up a session in a database. Everything the server needs to know — who you are, what you can do, when the token expires — is encoded right inside the token itself.

JWT Structure: Header, Payload, Signature

Every JWT consists of three parts separated by dots (.):

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

Each part is Base64URL-encoded JSON:

• Header — Declares the token type ("typ": "JWT") and the signing algorithm ("alg": "HS256", "RS256", etc.). This tells the verifier how the signature was created.
• Payload — Contains the actual data, called claims. This is where user identity, permissions, and expiration info live.
• Signature — A cryptographic hash of the header and payload, signed with a secret key (HMAC) or a private key (RSA/ECDSA). This prevents tampering.

Decoding a JWT means Base64URL-decoding the first two parts to read the header and payload as plain JSON. The signature part can't be "decoded" in the same way — it's a raw cryptographic value.

Common JWT Claims You'll Encounter

The JWT spec defines several registered claims that most tokens include:

• iss (Issuer) — Who created the token, e.g. "https://auth.example.com".
• sub (Subject) — The user or entity the token represents, typically a user ID.
• aud (Audience) — The intended recipient of the token, e.g. "my-api.example.com".
• exp (Expiration Time) — A Unix timestamp after which the token is invalid. This is the claim you'll check most often when debugging.
• iat (Issued At) — When the token was created. Useful for calculating token age.
• nbf (Not Before) — The token shouldn't be accepted before this time. Less common but important for scheduled activations.

Beyond these, tokens often carry custom claims like role, permissions, email, or org_id. These are application-specific and vary widely between providers.

Why You Need to Decode JWTs

You don't decode JWTs for fun. You decode them because something isn't working and you need to figure out why. Here are the most common reasons:

• Debugging 401/403 errors — Is the token expired? Is the audience claim wrong? Is the user missing a required role? Decoding the token answers all of these instantly.
• Checking token expiration — Convert the exp claim from a Unix timestamp to a human-readable date and see exactly when it expires (or when it already expired).
• Verifying claims before deployment — When setting up a new auth integration, decode a sample token to confirm it contains the claims your API expects.
• Comparing tokens across environments — Why does auth work in staging but not production? Decode both tokens and diff the payloads.

Security: Decoding Is Not Verification

This is the single most important thing to understand about JWTs: anyone can decode a JWT. The header and payload are just Base64URL-encoded — not encrypted. You can decode them in a browser with a single line of JavaScript. There's no key required.

Decoding tells you what the token says. Verification tells you whether to trust it. Verification requires checking the signature against the issuer's key. Without verification, a token could be forged, expired, or tampered with.

Key security rules to remember:

• Never trust an unverified JWT. Always verify the signature on your server before acting on any claims.
• JWTs are not encrypted by default. Don't put sensitive data (passwords, credit card numbers, secrets) in JWT payloads. Anyone who intercepts the token can read the contents.
• Always check exp. An expired token should be rejected, period.
• Validate the aud claim. A token meant for Service A should not be accepted by Service B.

Real-World Debugging Scenarios

The Expired Token

Your frontend suddenly gets 401 errors. You grab the token from the request header, decode it, and see that exp is 1742200800 — that was two hours ago. The refresh token logic has a bug. Now you know exactly where to look instead of guessing.

The Wrong Audience

You're integrating a third-party auth provider. Everything looks correct, but your API keeps rejecting the token. You decode it and find "aud": "dev-api.example.com" instead of "aud": "api.example.com". The OAuth app is still configured for the dev environment. A five-second decode saved an hour of head-scratching.

Missing Claims

Your authorization middleware expects a role claim, but users are getting permission denied. You decode the token and see there's no role field at all — the identity provider isn't including it. You need to update the auth config to request the right scopes.

JWT debugging doesn't have to involve console logging, manual Base64 decoding, or pasting tokens into sketchy websites that might be logging your data. A good decoder runs entirely in your browser, shows you the header and payload in clean formatted JSON, converts timestamps to readable dates, and highlights whether the token is expired.