JWT Decoder
Decode JWT tokens into header, payload, and signature without a secret.
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 whetherexphas passed, whetheraudmatches the expected audience, and whether the claims look right. - Confirm role and tenant claims. Many APIs put
roles,org_id, orpermissionsin 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) andkidso you can confirm the right signing key was used. - Inspect tokens during local development. Frontend engineers paste tokens out of
localStorageor 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
- Copy your JWT from the network panel, a cookie,
Authorization: Bearer ...header, orlocalStorage. - Paste it into the JWT Token textarea. The decoder accepts the raw token without the
Bearerprefix. - Read the decoded Header and Payload side by side. The output updates as you type.
- Copy either pane with its individual copy control to drop the JSON into a bug report or chat thread.
- 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.
| Part | Format | Purpose |
|---|---|---|
| Header | JSON object, Base64URL | Algorithm (alg), type (typ), optional key ID (kid) |
| Payload | JSON object, Base64URL | Claims about the subject and the token itself |
| Signature | Bytes, Base64URL | Proof 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.
| Claim | Name | Example | Meaning |
|---|---|---|---|
iss | Issuer | https://auth.example.com | Who minted the token |
sub | Subject | user_42 | Whom the token is about |
aud | Audience | api.example.com | Who the token is for |
exp | Expiration | 1705274000 | Unix seconds when the token stops being valid |
nbf | Not before | 1705270400 | Earliest time the token is valid |
iat | Issued at | 1705270400 | When the token was created |
jti | JWT ID | a3f1... | 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
subandscope. - 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
expto a human-readable date with the Unix Timestamp Converter to verify expected session lengths. - Multi-tenant routing. Engineers building B2B apps decode the
org_idortenantclaim 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
| Tool | Best for | Offline | Cost | Limitations |
|---|---|---|---|---|
| This JWT decoder | Fast in-browser inspection | Yes | Free | Does not verify signatures |
jwt.io debugger | Verify signatures with pasted keys | No | Free | Sends tokens to a third-party site |
pyjwt / jose libraries | Decode and verify inside code | Yes | Free | Requires a script and dependencies |
step CLI | Decode, verify, mint tokens | Yes | Free | Command 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.
Related tools
- Base64 Encoder / Decoder: Decode individual JWT segments by hand or encode binary payloads for API transport.
- URL Encode / Decode: Decode tokens that arrived percent-encoded in query parameters.
- HTML Escape / Unescape: Escape strings before rendering them in HTML to prevent injection.
- JavaScript Escape: Escape strings for safe embedding inside JavaScript source.
Related tools
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.