JWT Decoder Online — Decode JSON Web Tokens Instantly

What is this JWT decoder?

A JWT decoder online helps you read the header and payload of a JSON Web Token: two JSON documents plus a signature segment, carried in a compact URL-safe string. The header usually names the signing algorithm; the payload often includes sub, time windows such as exp, and app-specific fields. A signed JWT is three Base64url-encoded pieces separated by dots: header.payload.signature. The issuer signs the bytes header.payload; recipients verify with the right key. Unsigned “tokens” with only header and payload appear in some tests—treat them as unauthenticated unless policy says otherwise.

This page is for inspection and debugging only. Decoding is not verification. Anyone can read header and payload; trust comes from signature checks, issuer and audience validation, and time windows on your server. For more narrative context, see JWT explained for busy developers on the blog.

How to use this JWT decoder online

1. Paste the full token into the field above.
2. Read the pretty-printed header and payload. If exp or nbf are present, compare them to your local clock as a rough freshness signal—clocks can skew.
3. Confirm the algorithm in the header matches what your authorization server issued. Mismatches between symmetric (for example HS256) and asymmetric (RS256, ES256) keys are a frequent source of 401 responses.
4. Never paste production bearer tokens you are not allowed to share into untrusted services. This tool runs the decode in your browser, but you remain responsible for data-handling policy.

When you need test fixtures, our Base64 text tools complement JWT work by re-encoding strings without extra desktop software.

Example

A minimal OpenID subject claim might be just sub and exp. An OAuth access token for APIs might add scope strings, tenant IDs, and client identifiers. If the middle segment is not JSON—encrypted JWE, opaque value, or proprietary format—this tool will show a decode error, which is expected. Consult your provider’s docs and use official token introspection for critical data.

If you are also publishing JWT documentation and tool URLs, add them to a sitemap: use the sitemap generator and list hubs such as all tools and Base64 encode so crawlers see your public routes.

Common errors

• Assuming decode means “trusted” — the signature is what establishes authenticity. Use your stack’s official JWT validation for authorization decisions.
• Algorithm confusion — header says one algorithm, server expects another; verification fails with opaque errors until you align keys and config.
• Expecting JSON in every payload — JWE or opaque tokens may not decode as JSON here; that is normal.
• Leaked bearer tokens — treat decode-and-display as a leak if the token is still valid; rotate and design for replay until expiry or revocation.

Use cases

Teams use JWTs for OAuth 2.0 and OpenID Connect, API gateways, microservice-to-microservice auth, and single sign-on. Developers decode locally to debug login flows, compare claims to documentation, and check exp in integration tests. Always validate signatures, issuer, audience, and time windows in production using trusted libraries. Prefer short-lived access tokens, HTTPS, and secure client storage. When you ship new guides, cross-link from the blog to the relevant tools so readers and search engines see the connection. Performance on static pages (like this decoder) also supports SEO, but clarity supports humans first.

How this JWT decode step works (step by step)

The string splits on . into segments. The header and payload segments are Base64url-decoded (not standard Base64) into UTF-8 text, then parsed as JSON when possible. The signature segment is left as a binary blob for display—verifying it means loading keys and running the right MAC or asymmetric check, which is out of scope for a public browser page.

JWT token structure breakdown

header.payload.signature Each part is independently Base64url-encoded. Symmetric signing (HS256) and asymmetric (RS256, ES256) differ in key material, not in how you decode the first two parts for reading.

Common JWT claims explained

• sub — subject (often user id)
• iss / aud — issuer and audience for validation
• exp / iat / nbf — expiry, issued-at, and not-before in Unix seconds

Decode vs verify: why it matters

Anyone can decode a JWT; only holders of the right keys can verify that the issuer signed it. Skipping verification in APIs is a critical security bug—use this page only to understand what a token says, not to accept it in production.

API and code examples

In code, use your framework’s official JWT library (e.g. jose, PyJWT, or language equivalents) to verify. For quick inspection only, the browser tool mirrors what those libraries read before crypto.