JWT Decoder — Decode & Inspect JSON Web Tokens

This free JWT decoder reads and inspects JSON Web Tokens, showing the header, payload, and signature of any token. A JWT (defined in RFC 7519) is three Base64URL segments joined by dots; the header and payload are only encoded, not encrypted, so anyone can read their claims — which is why you must never store secrets in a token. It surfaces standard claims like exp, iat, iss, and aud. This decoder runs entirely in your browser, so tokens you paste never leave your device.

How JWT decoding works

A JSON Web Token (JWT) consists of three Base64url-encoded parts separated by dots: Header.Payload.Signature. The header contains the algorithm type (e.g., HS256, RS256). The payload contains claims — standard fields like sub (subject), iat (issued at), exp (expiry), and aud (audience), plus any custom claims added by the application. The signature is a cryptographic hash of the header and payload.

This tool decodes the header and payload by Base64url-decoding each segment and parsing the resulting JSON. The expiry timestamp (exp) is displayed as a human-readable date. Important: decoding a JWT does not verify its authenticity — the signature is not validated here, as that requires the secret key or public key from the server. A decoded JWT shows you what claims it contains; only server-side signature verification confirms those claims are trustworthy. Never trust decoded JWT claims for access control in a browser.

Related tools

Base64 → JSON formatter → Regex tester →

Related Guide: Learn more about JWT Security Best Practices

The three parts of a JWT

A JSON Web Token is three Base64URL segments joined by dots: header.payload.signature. The header names the signing algorithm, the payload holds claims (user id, roles, expiry), and the signature is a cryptographic seal over the first two parts. Decoding the first two is trivial — which is the single most important security fact about JWTs.

Encoded is not encrypted

Anyone holding a standard JWT can read its payload; Base64 is reversible. Never store passwords, card numbers or other secrets in a token. The signature doesn't hide data — it only lets the server detect tampering. If you need the contents hidden as well as verified, use an encrypted JWE instead.

Always verify server-side

A server must validate the signature with its secret or public key, check exp (expiry) and iat/nbf timestamps, and confirm the iss and aud claims before trusting anything. Critically, reject tokens whose header asks for alg: none and pin the expected algorithm — accepting attacker-chosen algorithms is a well-known JWT exploit. This decoder runs entirely in your browser, so tokens you paste never leave your device.

⚠️ Common Mistakes to Avoid

Frequently asked questions

Is my JWT sent to a server?

No, decoding happens entirely in your browser. Your sensitive token data never leaves your machine.

What are the three parts of a JWT?

A JWT consists of a Header (algorithm/type), a Payload (claims), and a Signature (security).

Related guides

What is JWT? → JWT Security Best Practices → 7 JWT Mistakes in Production →
Reviewed by the ToolsmithPro editorial team · Last updated June 2026. Every calculation and conversion runs entirely in your browser — your inputs are never uploaded, stored or shared. Formulas and methodology are documented on our about page; spot an error? tell us and we'll fix it.