ToolBench

JWT Decoder

Decode a JWT's header and payload to readable JSON, right in your browser. This only decodes the token — it does not verify the signature.

0 chars0 lines0 bytes

Decoded header and payload will appear here…

What is JWT Decoder?

JWT Decoder is a browser-based tool that takes a JSON Web Token and shows its header and payload as readable, formatted JSON. It also interprets the standard timing claims — issued-at, not-before, and expiry — telling you when the token was created, when it becomes valid, and whether it has expired. The signature is displayed but not verified.

A JWT is a compact, URL-safe token made of three base64url-encoded parts separated by dots: a header describing the signing algorithm, a payload of claims (the actual data), and a signature. JWTs are the backbone of modern stateless authentication and authorization — after login, a server issues a signed token that the client sends on each request to prove who it is and what it may do.

Because the header and payload are only base64url-encoded, not encrypted, anyone can decode and read them. This tool makes that instant and readable for debugging. Everything happens locally in your browser — the token, which may be a real session credential, is never uploaded.

Why use JWT Decoder?

When debugging authentication, you constantly need to see what a token actually contains — which user it identifies, what roles or scopes it grants, and when it expires. Reading the raw base64url string by eye is impossible. This decoder turns it into clean JSON instantly, so you can confirm the claims are what you expect.

The timing interpretation answers the most common JWT question: "is this token still valid?" By decoding the exp, nbf, and iat claims into human-readable dates and a valid/expired status, the tool immediately tells you whether an authentication failure is due to an expired token rather than a wrong signature or a server bug.

Decoding locally is important because a JWT is a live credential. Pasting a real session token into an online service that sends it to a server could expose your account. This tool decodes everything in the browser with zero network requests — verifiable in the Network tab — so your tokens stay private.

Features

  • Decodes the JWT header and payload to formatted JSON
  • Interprets iat, nbf, and exp timing claims as readable dates
  • Shows a valid / expired / not-yet-valid status at a glance
  • Displays the signature (without verifying it)
  • Live decoding as you paste
  • Clear errors for malformed tokens
  • Copy or download the header and payload JSON
  • Runs entirely in your browser — no uploads, works offline

How to use JWT Decoder

  1. Paste a JWT — the three dot-separated parts — into the input panel on the left.
  2. The decoded header and payload appear immediately as formatted JSON.
  3. Check the status message and the timing claims to see whether the token is currently valid or expired.
  4. Copy or download the header or payload JSON using the buttons in each subpanel.
  5. Paste a different token at any time to decode it live.

Example 1 — Decode the payload

Paste a token to see its payload claims as readable JSON, including the subject and any roles.

Input

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJyb2xlIjoiYWRtaW4ifQ.sig

Output

{
  "sub": "123",
  "role": "admin"
}

Example 2 — Check expiry

A token whose exp claim is in the past is reported as expired, with the exact expiry time shown.

Input

a JWT with exp set to a past timestamp

Output

Status: This token has expired. exp: (past date shown)

Common Mistakes

  • Assuming a JWT is encrypted: the header and payload are only base64url-encoded, not encrypted. Anyone can read them. Never put secrets in a JWT payload — treat everything in it as public.
  • Trusting a decoded token without verifying its signature: decoding proves what the token claims, not that the claims are authentic. This tool does not verify the signature, so a decoded payload could have been forged. Real validation must check the signature server-side.
  • Confusing "valid timing" with "valid token": a token can be within its exp/nbf window but still be forged or revoked. The valid status here only reflects the timing claims, not signature or revocation checks.
  • Pasting only part of the token: a JWT needs all three dot-separated segments. Copying just the payload, or truncating the signature, produces a malformed-token error.
  • Treating timestamps as milliseconds: JWT timing claims (iat, nbf, exp) are Unix seconds, not milliseconds. Interpreting them as milliseconds places them in 1970.
  • Sharing a real token to debug it: a live JWT is a credential. Pasting it into an untrusted online tool that transmits it can hand over your session. Always use a decoder that works locally.

Developer Tips

  • When an API returns 401, decode the token here first — an expired exp claim is the single most common cause and is immediately visible.
  • Confirm the payload contains the roles, scopes, or tenant claims your authorization logic expects; mismatched claims often explain "forbidden" errors that are not actually about the signature.
  • Remember the header's alg field tells you how the token was signed — an unexpected alg like "none" is a red flag worth investigating for security issues.
  • Because timing claims are Unix seconds, you can paste them into the Timestamp Converter to cross-check exact issue and expiry times in your local timezone.
  • Never rely on client-side decoding for authorization decisions — always verify the signature and claims on the server, where the token cannot be tampered with.

Frequently Asked Questions

What are the three parts of a JWT?
A JWT has three base64url-encoded sections separated by dots: the header, the payload, and the signature. The header identifies the token type and the signing algorithm (the alg field). The payload contains the claims — the actual data, such as the user id, roles, and timing information. The signature is computed over the header and payload using a secret or private key and is what allows a server to verify the token has not been tampered with. This tool decodes the header and payload and displays the signature without verifying it.
Does this tool verify the token's signature?
No. It decodes and displays the header and payload and shows the signature, but it does not verify that the signature is valid. Verification requires the signing secret or public key and must be done in a trusted environment, normally on the server. This means a decoded payload shown here proves only what the token claims, not that those claims are genuine — a forged token would decode just fine. Always validate signatures server-side before trusting a token.
Is it safe to paste a real token here?
Yes, because all decoding happens locally in your browser and the token is never sent anywhere. That said, a JWT is a live credential, so you should only ever paste one into a decoder you trust to work entirely client-side. You can confirm this tool makes no network requests by watching your browser's Network tab while decoding — there are zero outbound requests, and it works offline. Never paste a real token into a tool that transmits it to a server.
Why can everyone read the contents of my JWT?
Because a standard JWT is signed, not encrypted. The header and payload are merely base64url-encoded, which is trivially reversible — anyone with the token can decode and read every claim. Signing protects integrity (detecting tampering), not confidentiality. For this reason you must never place sensitive information such as passwords or secrets in a JWT payload. If you need the contents hidden, you would use an encrypted variant (JWE), which is different from a standard signed JWT.
How do I know if a token is expired?
The tool reads the exp (expiration) claim, which is a Unix timestamp in seconds, and compares it to the current time, reporting the token as expired, valid, or not-yet-valid (based on the nbf claim). It also shows the exact issued-at, not-before, and expiry dates in readable form. Keep in mind this reflects only the timing claims — a token can be past its expiry (definitely unusable) or within its window (possibly still forged or revoked), so timing validity is necessary but not sufficient for a token to be trustworthy.
What format are the timing claims in?
The standard JWT timing claims — iat (issued at), nbf (not before), and exp (expiration) — are all NumericDate values, meaning the number of seconds since the Unix epoch (1 January 1970 UTC). A frequent mistake is to interpret them as milliseconds, which would place the dates in 1970. This tool converts them to readable local dates for you. If you need to double-check a raw value, you can paste it into a Unix timestamp converter, remembering it is in seconds.