Skip to main content

JWT Decoder

Decode a JSON Web Token to inspect its header, payload, and expiry — without sending it anywhere.

Written by Golam Rabbani, Founder & Lead Engineer

Paste the full token (header.payload.signature). Decoded entirely in your browser — nothing is sent to any server.

How to use this jwt decoder

  1. Paste your full JWT string into the "JWT String" field.
  2. Press Decode to split and decode the token in your browser.
  3. Read the Header and Payload sections to inspect the algorithm, type, and claims.
  4. Check the expiry banner — the tool shows "Valid (expires in …)" or "Expired" based on the `exp` claim.
  5. Use "Copy header + payload" to copy the combined JSON to your clipboard, or Reset to clear everything.

About this jwt decoder

The JWT decoder takes a JSON Web Token and splits it into its three dot-separated segments — header, payload, and signature — then base64url-decodes the first two and pretty-prints them as JSON so you can read each claim at a glance.

A JWT (defined in RFC 7519) carries three base64url-encoded segments joined by dots: the header, the payload, and the signature. The header typically contains the signing algorithm (`alg`, e.g. HS256 or RS256) and token type (`typ`). The payload carries registered and custom claims: `sub` (subject), `iss` (issuer), `aud` (audience), `iat` (issued-at Unix timestamp), `exp` (expiry Unix timestamp), and any application-specific fields. The signature is produced by the server using a secret or private key and proves the token has not been tampered with — but this tool does not verify it. Decoding reveals what the token claims; only a signature check against the correct key tells you whether to trust those claims. All decoding happens locally in your browser and nothing is transmitted, but a JWT can still carry sensitive claims, so avoid pasting real production tokens into any online tool.

For example, a payload of `{"sub":"123","name":"Ada","exp":1714000000}` decodes instantly — the tool displays the pretty-printed JSON and resolves the `exp` timestamp to show either "Valid (expires in X days)" or "Expired", along with the exact ISO-8601 expiry date. Developers, QA engineers, and anyone debugging an authentication flow will find this useful for inspecting tokens without needing a local script.

FAQ

What does the JWT decoder actually show me?
It base64url-decodes the header and payload segments and pretty-prints them as JSON so you can read the algorithm, token type, and every claim. It also resolves the `exp` and `iat` Unix timestamps to human-readable ISO-8601 dates and shows whether the token is currently valid or expired.
Why is decoding a JWT without signature verification limited?
Decoding only tells you what the token claims. Without verifying the signature against the signing key, you cannot know whether those claims are genuine — anyone can craft a token with any payload. Signature verification must happen server-side using the secret (for HMAC algorithms) or the public key (for RSA/ECDSA algorithms).
Where should signatures actually be verified?
On the server that receives the token. The server holds the secret key or trusted public key and uses a library (e.g. `jsonwebtoken` in Node.js, `PyJWT` in Python) to validate the signature, expiry, issuer, and audience before trusting any claim.
What are the most common JWT claims and what do they mean?
`sub` is the subject (usually a user ID), `iss` is the issuer, `aud` is the intended audience, `iat` is the Unix timestamp when the token was issued, and `exp` is the Unix timestamp after which the token is no longer valid. All are optional but widely used.
What does the `exp` claim mean and how does the tool use it?
`exp` is a Unix timestamp (seconds since 1970-01-01T00:00:00Z) indicating when the token expires. The tool compares it to the current time and displays either "Valid (expires in …)" with a relative duration or "Expired" in red, alongside the exact ISO-8601 expiry date.
Is it safe to paste a real token into this tool?
The decoder runs entirely in your browser — nothing is sent to a server. However, a JWT can carry sensitive claims (user ID, roles, email). Treat any token as sensitive: avoid pasting real production tokens into online tools as a general security practice, even client-side ones.