JWT Decoder

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe token format defined by RFC 7519 for representing claims between two parties. A claim is a statement about a subject — typically a user — along with any additional metadata the issuer wants to attach. JWTs are the dominant mechanism for stateless authentication in single-page applications, REST APIs, and OpenID Connect (OIDC) identity flows. When a user logs in, the server issues a JWT; the client stores it and sends it with every subsequent request. The server can verify the token and extract the user's identity without querying a session store. Backend engineers, frontend developers, and security reviewers all need to inspect JWT contents regularly — this json web token decoder does that instantly in the browser.

Anatomy of a JWT

Every JWT is three base64url-encoded strings joined by dots: header.payload.signature. To decode a JWT, split on the dots and base64url-decode each of the first two parts. The third part is the cryptographic signature — it cannot be decoded into human-readable data.

Header

The header is a small JSON object that describes the token itself. The two standard fields are alg (the signing algorithm) and typ (always JWT). Common algorithm values are HS256 (HMAC-SHA256, symmetric) and RS256 (RSA-SHA256, asymmetric). The alg value matters for verification; if you see none, treat the token as untrusted.

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

The payload contains the claims. This is where the user's identity and any application-specific data lives. This is also the most misunderstood part of JWTs: the payload is base64-encoded, not encrypted. Anyone who has the token — including the end user — can decode and read the payload without any key. Never put passwords, secret keys, or confidential PII in a JWT payload unless the token is additionally encrypted (that is JWE, not JWT). A typical payload looks like this:

{
  "sub": "user_01HZ93",
  "name": "Alice",
  "email": "alice@example.com",
  "role": "admin",
  "iat": 1714000000,
  "exp": 1714086400
}

Signature

The signature is computed over the base64url-encoded header and payload using the algorithm specified in alg and a secret or private key held by the issuer. It is a cryptographic MAC or digital signature — not a data encoding. You cannot decode the signature into something readable; its sole purpose is to let the recipient verify that the header and payload have not been tampered with since the token was issued. A jwt parser that shows you the raw bytes of the signature does nothing useful — what matters is whether verification passes on the server.

How to use this JWT decoder

1. Paste your JWT string into the input box. The token should look like three dot-separated strings of random-looking characters.
2. Click Decode (or the tool decodes automatically as you type). The header and payload are displayed as formatted JSON.
3. No token handy? Click Sample to load a demo token — most jwt decoder tools on the web skip this, but it lets you explore the format without needing a real token.
4. Use Copy header or Copy payload to put the decoded JSON on your clipboard for further inspection or pasting into a ticket or log.
5. Click Clear to reset the input and outputs and start with a fresh token.
6. If the token is malformed — wrong number of segments, invalid base64url characters — an inline error is shown immediately.

Why this tool does not verify signatures

Signature verification is intentionally absent, and that is the right design choice. Here is why.

Verifying an HS256 signature requires the shared secret. Verifying an RS256 or ES256 signature requires the issuer's public key. The shared secret is, by definition, a production credential — it is the same value your server uses to sign every token it issues. Pasting that secret into any web tool is a security incident waiting to happen. You have no way to verify that the JavaScript on the page is not exfiltrating your input, and you cannot audit what a future deploy of that site might do. Even a tool that is genuinely client-side today can be compromised tomorrow.

If you need to verify a JWT signature, do it in your backend, in a local CLI you control, or in a unit test — not in a browser tab. The right tool for signature verification is your language's JWT library (jsonwebtoken in Node.js, PyJWT in Python, and so on), running against your own key material.

More practically: the overwhelming majority of JWT debugging does not require signature verification at all. Ninety-five percent of the time, the problem is an expired token (exp in the past), the wrong audience (aud mismatch), a missing claim, or a typo in the subject. A jwt parser that shows you the decoded payload answers all of those questions immediately.

Finally, a direct warning: if a JWT decoder offers a secret field for signature verification, treat it as a phishing site. Legitimate decode-only tools have no reason to ask for your signing secret.

Common JWT claims

RFC 7519 §4.1 defines a set of registered claim names. These are not mandatory, but they are standard and well-understood by every JWT library.

• iss — issuer: identifies who created and signed the token (e.g. https://auth.example.com).
• sub — subject: the principal this token represents, usually a user ID or account identifier.
• aud — audience: identifies the recipients the token is intended for; the server should reject tokens where aud does not match.
• exp — expiration time: a Unix timestamp after which the token must not be accepted; the most common source of auth failures.
• nbf — not before: a Unix timestamp before which the token is not yet valid; used for delayed-activation tokens.
• iat — issued at: a Unix timestamp recording when the token was created; useful for calculating token age.
• jti — JWT ID: a unique identifier for the token, used for revocation lists and preventing replay attacks.

Frequently asked questions

Is my JWT sent anywhere?

No. Decoding is 100% client-side. The tool splits the token string on dots and calls base64url decoding entirely in your browser using standard JavaScript. No network request is made with your token, and nothing is logged or stored. You can safely paste tokens from development or staging environments.

Why does my decoded payload look fine but auth still fails?

Decoding and verifying are different operations. A token can decode perfectly — the JSON is valid, the claims look right — but still be rejected by your server. The most common reasons: the exp timestamp is in the past (token expired), the aud or iss claim does not match what the server expects, or signature verification fails because the token was signed with a different key or was tampered with in transit. Check the timestamp fields first — convert the exp value from Unix epoch to a readable date using a Unix timestamp converter.

Can I decode a JWT without the secret?

Yes — that is exactly the point of this tool. The header and payload segments are base64url-encoded, not encrypted. Any party that holds the raw token string can decode and read the payload contents. The secret (or private key) is only required to verify the signature, which proves the token was issued by a trusted party and has not been altered. Decoding requires no key. If a tool asks for your secret to show you the payload, something is wrong.

What is the difference between JWE and JWT?

A standard JWT is a JWS (JSON Web Signature) — the payload is base64url-encoded and therefore readable by anyone who has the token. A JWE (JSON Web Encryption) encrypts the payload so that only the intended recipient with the correct key can read the claims. JWEs have five dot-separated segments instead of three, and the payload is ciphertext, not plain JSON. This tool decodes standard JWTs (the vast majority of real-world usage). It does not support JWEs.

Is JWT secure?

JWT is a transport format, not a security guarantee. Whether a JWT-based system is secure depends on several independent factors: the algorithm chosen (none and weak HS256 secrets are dangerous; RS256/ES256 with proper key management are strong), rigorous signature verification on every receiving endpoint, HTTPS for all token transport (JWTs are readable in plaintext, so a network-level attacker who can intercept the token can read the claims), short exp lifetimes to limit the blast radius of a stolen token, and a revocation strategy for long-lived tokens where the jti claim is useful.

What if my JWT has only two segments?

A well-formed JWT has exactly three dot-separated segments. A token with two segments is either malformed or an unsecured JWS with alg: none — a format that omits the signature entirely. The alg: none bypass was a real attack vector against older JWT libraries that accepted it. Modern libraries reject none by default. If you receive a two-segment token from a production system, that is a red flag worth investigating before you do anything else.