Home/Developer Tools/JWT Decoder
[ DEV.1 — JWT ]

JWT Decoder

A JSON Web Token (JWT) is a compact, URL-safe token format used for authentication and information exchange. It consists of three base64url-encoded segments — header, payload, and signature — separated by dots. This tool decodes the header and payload so you can inspect the claims.

Last reviewed: May 2026

// Everything runs locally in your browser — nothing is sent to our servers.
// paste a JSON web token 0 chars
Runs entirely in your browser. Nothing is sent to our servers — no network call, no logging, no storage. This tool decodes only — it does not verify signatures or create tokens.
HEADER PAYLOAD SIGNATURE

Need to encode or decode Base64?

Open Base64 tool →
DEV.2

Base64 Encode/Decode

Encode and decode base64 and base64url strings — sibling tool to the JWT segment encoding.
DEV.3

Hash Generator

Generate SHA-256, SHA-1, MD5, and other digests — useful for HS256 signing experiments.
W.2

HTTP Security Headers

Inspect Authorization: Bearer … and the rest of the headers your client sends and receives.
→

All Developer Tools

JWT, Base64, hashes, and the rest of the Network Lookup developer utility hub.

What is a JWT?

A JSON Web Token (JWT, often pronounced "jot") is a compact, URL-safe way to transmit signed claims between two parties. It's defined by RFC 7519 and is the most common token format for modern web authentication — OAuth 2.0 access tokens, OpenID Connect ID tokens, "remember me" session cookies, password-reset links, single-sign-on assertions, and signed API requests all routinely ride on JWTs.

A JWT looks like one long opaque string with two dots in it: aaa.bbb.ccc. Each section is base64url-encoded. The first section is the header (which algorithm signed this), the second is the payload (the actual claims — who you are, what you can do, when it expires), and the third is the signature (a MAC or asymmetric signature that lets the recipient confirm the first two parts haven't been tampered with).

The encoding is not encryption. Anyone who has the token can read the header and payload — that's exactly what this decoder does. The signature is what gives the token integrity; without the signing key you cannot mint a new valid token, but you can absolutely read every claim in any token you intercept. If you need confidentiality on top of integrity, you want JWE (JSON Web Encryption), which is a separate spec.

Security warnings

JWTs often contain sensitive information. User IDs, email addresses, session data, OAuth scopes, role claims, sometimes even raw permission flags — they can all sit in the payload. Be careful pasting production tokens into any third-party tool. This decoder runs in your browser only and never makes a network call, but it's still a good habit to revoke a token after decoding it for debugging if it carried sensitive data.
This tool decodes only. It does not verify the signature (that needs the secret or public key, which we don't ask for) and does not create or sign new tokens. If a verifier needs to trust a JWT, signature verification is mandatory — never accept the payload from an unverified token.

The three parts, in detail

1. Header

A small JSON object that names the algorithm and the token type. Almost always two fields:

  • alg — the signing algorithm. Common values: HS256 (HMAC-SHA256, symmetric, uses a shared secret), RS256 (RSA-SHA256, asymmetric, public/private key pair), ES256 (ECDSA P-256, asymmetric), EdDSA (Ed25519). The dangerous value none means "no signature" and any compliant verifier must reject it explicitly.
  • typ — almost always the literal string "JWT".

Optional fields you'll see in the wild: kid (key ID — which signing key was used, important when keys rotate), jku / jwk / x5u (key hints — these are dangerous to follow blindly), cty (content type, for nested tokens).

2. Payload

The actual claims. RFC 7519 defines seven registered claim names that are universally understood; everything else is application-specific.

  • iss — issuer (who minted this token)
  • sub — subject (who the token is about, usually a user ID)
  • aud — audience (who the token is for)
  • exp — expiration (Unix seconds; after this time the token must be rejected)
  • nbf — not before (Unix seconds; before this time the token must be rejected)
  • iat — issued at (Unix seconds)
  • jti — unique token ID (for revocation lists)

3. Signature

The third segment is the signature over base64url(header) + "." + base64url(payload), computed with the algorithm named in the header and the appropriate key. The verifier reads alg, recomputes the signature, and compares — if they don't match (or if alg is something the verifier doesn't allow), the token is rejected. This is the only thing that prevents an attacker from minting their own tokens.

Common JWT mistakes

  • Trusting the alg field blindly. Always pin acceptable algorithms server-side. The classic "alg: none" and "RS256 → HS256 key confusion" attacks both exploit servers that derived the algorithm from the token instead of from configuration.
  • Treating the payload as encrypted. It isn't. Don't put secrets in claims.
  • Long-lived access tokens with no revocation path. If you can't invalidate a token, set short exp windows and use refresh tokens.
  • Skipping aud checks. A token issued for service A can be replayed against service B if neither checks aud.
  • Storing JWTs in localStorage. XSS reads them. Prefer HttpOnly cookies for browser sessions when you can.

Frequently asked questions

Is my token safe?

Yes. This decoder runs entirely in your browser — there is no fetch call, no server-side processing, no logging, and nothing is stored. The token you paste never leaves your device. You can verify this by opening your browser's network tab while you decode a token; you won't see any outbound request related to the token.

That said: if the token you're debugging is a real production token, get into the habit of revoking it (rotating the session, signing out, invalidating the jti) once you're done debugging. It's good hygiene regardless of which tool you used.

Why can't you verify the signature?

Verifying a JWT signature requires the secret (for symmetric algorithms like HS256/HS384/HS512) or the public key (for asymmetric algorithms like RS256, ES256, EdDSA) that the token was signed with. Asking users to paste their signing secret into a public website is a serious security anti-pattern, so this tool intentionally does not request or accept it.

Verify signatures in your backend, in a trusted local CLI like jwt-cli, or in a runtime you control end-to-end. If you're chasing a verification bug, the signature is almost never the problem — it's usually a clock skew on exp/nbf, a key-ID mismatch, or a different alg than the verifier expects.

How do I read exp / iat / nbf?

All three are Unix epoch timestamps measured in seconds (not milliseconds — a common bug when developers compare against Date.now(), which returns milliseconds). iat is when the token was issued, exp is when it expires, and nbf is "not before" — the earliest moment it can be accepted.

This decoder converts each to a human-readable date and a relative time like "expires in 2h 14m" or "expired 3 days ago", so you don't have to do the math.

What's the difference between header, payload, and signature?

The header is a tiny JSON object that declares the signing algorithm (alg) and token type (typ). The payload is the JSON object of claims — standard ones like sub, iss, aud, exp plus any custom claims your application adds. The signature is a cryptographic MAC or signature computed over the base64url-encoded header and payload, joined by a dot, using the secret or private key.

The signature is what lets a recipient detect tampering. Without it, anyone could change the payload and reuse the token. With it, any change to the header or payload invalidates the signature.