ShotMark
Skip to Content

JWT Decoder

Decode JWT tokens into header, payload, and signature without a secret.

JWT Token
Decoded
Waiting for input

What is JWT Decoder?

A JWT decoder is a tool that splits a JSON Web Token into its three parts (header, payload, and signature) and renders the header and payload as readable JSON. JSON Web Tokens are specified in RFC 7519  and are the dominant format for bearer authentication in modern APIs. A JWT looks like three Base64URL-encoded segments joined by dots: header.payload.signature.

The decoder does not verify the signature, because that requires the issuer’s secret or public key. What it does is reveal what the server saw when it validated the token: the algorithm in the header, the user identity and claims in the payload, and the expiration timestamp. That is enough information to debug 90% of token-related auth failures without ever leaving the browser.

Why use a JWT decoder?

  • Diagnose 401 responses fast. When an API returns 401 Unauthorized, decoding the token shows whether exp has passed, whether aud matches the expected audience, and whether the claims look right.
  • Confirm role and tenant claims. Many APIs put roles, org_id, or permissions in the payload. A glance at the decoded JSON tells you why the user got a 403.
  • Validate token issuer and algorithm choices. The header reveals alg (HS256, RS256, EdDSA) and kid so you can confirm the right signing key was used.
  • Inspect tokens during local development. Frontend engineers paste tokens out of localStorage or cookies to verify the contract with the backend before wiring up a fetch call.
  • Stay local with sensitive tokens. The decoder runs entirely in your browser. Production tokens never reach a third-party server, which matters because anyone with a valid JWT can impersonate that user until it expires.

How to use the JWT Decoder

  1. Copy your JWT from the network panel, a cookie, Authorization: Bearer ... header, or localStorage.
  2. Paste it into the JWT Token textarea. The decoder accepts the raw token without the Bearer prefix.
  3. Read the decoded Header and Payload side by side. The output updates as you type.
  4. Copy either pane with its individual copy control to drop the JSON into a bug report or chat thread.
  5. If the token is malformed, an error message appears. Re-copy the token and watch for trailing whitespace or missing segments.

JWT structure

A JWT has three parts separated by . characters. Each part is independently Base64URL-encoded. The third part is a binary signature, not JSON.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzA1MjcwNDAwLCJleHAiOjE3MDUyNzQwMDB9.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk ^ ^ ^ | header (base64url JSON) | payload (base64url JSON) | signature (base64url bytes)

The header declares the signing algorithm and token type. The payload carries the claims. The signature is computed by the issuer over base64url(header).base64url(payload) using the algorithm named in the header.

PartFormatPurpose
HeaderJSON object, Base64URLAlgorithm (alg), type (typ), optional key ID (kid)
PayloadJSON object, Base64URLClaims about the subject and the token itself
SignatureBytes, Base64URLProof that the issuer minted the token with its key

Common JWT claims

RFC 7519 defines seven standard claims. Most issuers add custom claims on top. The decoder will show all of them as raw JSON.

ClaimNameExampleMeaning
issIssuerhttps://auth.example.comWho minted the token
subSubjectuser_42Whom the token is about
audAudienceapi.example.comWho the token is for
expExpiration1705274000Unix seconds when the token stops being valid
nbfNot before1705270400Earliest time the token is valid
iatIssued at1705270400When the token was created
jtiJWT IDa3f1...Unique token identifier, useful for revocation

A decoded payload from a real-looking token:

{ "iss": "https://auth.example.com", "sub": "user_42", "aud": "api.example.com", "iat": 1705270400, "exp": 1705274000, "roles": ["admin", "billing"], "org_id": "org_7Yt2" }

Common use cases

  • API debugging. Backend developers paste a captured token to confirm the gateway is forwarding the expected sub and scope.
  • Frontend auth integration. When a SPA receives a token from an OAuth provider, decoding it confirms which claims are available for the UI.
  • QA token expiry checks. QA engineers convert exp to a human-readable date with the Unix Timestamp Converter to verify expected session lengths.
  • Multi-tenant routing. Engineers building B2B apps decode the org_id or tenant claim to verify the tenant resolver picks the right database.
  • Bug report enrichment. Pasting a decoded payload into a bug ticket gives the developer the exact user state without a separate identity lookup.

JWT decoder vs alternatives

ToolBest forOfflineCostLimitations
This JWT decoderFast in-browser inspectionYesFreeDoes not verify signatures
jwt.io debuggerVerify signatures with pasted keysNoFreeSends tokens to a third-party site
pyjwt / jose librariesDecode and verify inside codeYesFreeRequires a script and dependencies
step CLIDecode, verify, mint tokensYesFreeCommand line only, install required

Frequently asked questions

Can I decode a JWT without the secret?

Yes. The header and payload are Base64URL-encoded JSON, not encrypted. Anyone who sees a JWT can read its contents. The secret is only needed to verify that the signature is valid, not to read the claims.

Is a JWT encrypted?

A standard signed JWT (JWS) is not encrypted. It is signed, which proves authenticity but not confidentiality. If you need confidentiality, use JWE (JSON Web Encryption) or send the token over TLS. Do not put passwords or other secrets in JWT claims.

Are JWTs secure?

A JWT is as secure as the key that signs it and the channel that carries it. Signed tokens prevent tampering, but a stolen token grants the bearer the same access as the original user until exp. Always serve tokens over HTTPS and store them somewhere XSS cannot reach (HttpOnly cookies are preferable to localStorage).

What is the difference between JWT, JWS, and JWE?

JWT is a generic claim format. JWS (JSON Web Signature) is the signed envelope, the form you see most often. JWE (JSON Web Encryption) is the encrypted envelope, used when the payload itself must be hidden from the bearer.

What does the alg field control?

alg names the signature algorithm: HS256 for HMAC-SHA256, RS256 for RSA, ES256 for ECDSA, EdDSA for Ed25519. The server must enforce the algorithm out-of-band; accepting alg: none is a classic vulnerability that lets attackers forge unsigned tokens.

Why does the decoder show two parts and not three?

The third part is a binary signature, not JSON. The decoder shows the header and payload because those are the human-readable segments. The signature is still present in the token; it just is not meaningful without the verification key.

How do I check if a JWT has expired?

Look at the exp claim in the decoded payload. It is a Unix timestamp in seconds. Convert it to a date with the Unix Timestamp Converter and compare to now.

Can I trust the claims in a decoded JWT?

Only if the signature has been verified. The decoder shows you what the token says, not what is true. A server must always verify the signature with the issuer’s public key before trusting any claim.

Like this tool?

ShotMark captures what you do here, in one click.

The traces, payloads, and tests you run by hand? ShotMark grabs the whole bug and hands it to your AI agent.

Private beta accessFounding pricing lockNo spam ever