U
UseCalcForge Free Online Calculators
Tools
Publishing Science Developer Finance
 
Health Marketing Lifestyle All Tools
Contact Us
Developer Tools

JWT Decoder.

Decode a JSON Web Token to inspect its header and payload, entirely client-side. Not a verifier.

Not a valid JWT structure — expected three dot-separated parts (header.payload.signature).

Runs entirely in your browser. The values you enter never leave your device — there is no request to our server and nothing is stored. How we handle data

The Three Parts of a JWT

A JSON Web Token is three Base64Url-encoded segments joined by dots. The first two are plain JSON once decoded; the third is a cryptographic signature, not decodable data.

Structure

header.payload.signature
Header: algorithm + token type
Payload: claims (the actual data)
Signature: HMAC or RSA/ECDSA over header + payload

Base64Url is a URL-safe variant of standard Base64 — it replaces + and / with - and _ so the encoded token can appear directly in a URL or header without further escaping, and it usually omits the trailing = padding characters that standard Base64 requires.

Decoding Is Not Verifying

This is the single most important thing to understand about JWTs, and the most common source of security mistakes involving them.

The payload is encoded, not encrypted

Anyone holding a JWT can decode and read its full payload without any secret, exactly as this tool does. Never put genuinely secret data — a password, a full credit card number — inside a JWT payload, since it is readable by design.

The signature is what makes it trustworthy

Verifying the signature — checking it against the secret (HMAC) or public key (RSA/ECDSA) that created it — is what confirms the header and payload have not been altered since issuance. A decoder shows you the signature exists; it does not and cannot confirm the signature is valid.

A forged token still decodes cleanly

Anyone can hand-craft a header and payload, Base64Url-encode them, and attach any signature-shaped string — it will decode without error. Only checking the signature against the correct key distinguishes a genuine token from a forged one, which is why server-side verification is not optional.

Standard Claims Worth Recognising

The JWT specification defines a small set of standard, optional claim names, all three characters long by convention, which most tokens include alongside their own custom claims.

exp (expiration time) and iat (issued at) are both Unix timestamps in seconds, which this tool converts to a readable date automatically. Other common standard claims include sub (subject — usually a user ID), iss (issuer), and aud (audience — who the token is intended for). Anything beyond these is application-specific and defined by whichever service issued the token.

Knowledge Base

JSON Web Tokens Methodology.

A JWT packages a set of claims into a compact, URL-safe, signed structure. Reading its contents requires no secret at all, which is precisely why the signature — not the encoding — is what makes a JWT trustworthy, and why a decoder is a different tool from a verifier.

The Calculation Branch

JWT = Base64Url(header) + '.' + Base64Url(payload) + '.' + signature | Base64Url: standard Base64 with +/ replaced by -/_ and padding usually omitted | exp and iat claims are Unix timestamps in seconds

Industrial Standards.

Decoding is performed entirely in the browser using the same Base64Url-to-JSON process any JWT library implements: reversing the URL-safe character substitution, restoring standard Base64 padding, decoding to bytes, interpreting those bytes as UTF-8, and parsing the result as JSON. The signature segment is displayed as-is and never processed, since verifying it correctly requires the issuing party's secret or public key, which this client-side tool never has and should never be given.

In-Depth Analysis & Reference Data

JWTs are commonly used for stateless authentication: instead of looking up a session in a database on every request, a server issues a signed token once, and every subsequent request includes it, with the server checking the signature rather than a stored session record. This is why the exp claim matters so much — with no server-side session to revoke, a compromised token generally remains valid until it expires, unless the application implements a separate revocation mechanism.

The algorithm named in the header (commonly HS256, RS256, or ES256) tells a verifier which cryptographic method to use, and trusting the algorithm named in an untrusted token without cross-checking it against the expected algorithm is a known class of JWT vulnerability — a verifier should always confirm the algorithm matches what the application expects, not simply use whatever the token claims.

Registry Questions & FAQ.

Why does the signature look like gibberish while the header and payload are readable?

The header and payload are Base64Url-encoded JSON, which decodes back to structured text. The signature is the raw output of a cryptographic function (HMAC or a digital signature algorithm) — it is not encoded data at all, so there is nothing meaningful to decode from it.

Can I edit a JWT here and get a working token back?

This tool decodes only — it does not re-encode or re-sign. Even if you reconstructed the Base64Url encoding by hand, the original signature would no longer match the edited content, and any server correctly verifying signatures would reject the result.

All metrics verified against ISO/ASTM benchmarks.