Security Runs locally Ready to use Built-in examples No tracking

JWT Decoder

Paste a JWT to decode its header and payload locally, list registered claims and convert iat, nbf and exp to local time. The signature is not verified and the token is never uploaded.

Debugging a login endpoint usually means looking at what the token actually carries: the user ID, the issuer, whether the expiry is right. A JWT's header and payload are only base64url-encoded, not encrypted, so they can be read by unpacking the string locally. This tool decodes both segments into JSON, lists the fields, converts iat, nbf and exp into local time and flags whether the token has expired.

The boundary matters: this decodes, it does not verify. Seeing the contents does not make the token trustworthy — the signature segment is never checked, so anyone can forge what is inside. That makes it a tool for development and for chasing down a 401, not a place to paste a production token, and the decoded result must never be treated as proof of identity.

—
—
—
—
—

How to use

  1. Paste the JWT.
  2. Read the decoded header and payload.
  3. Check the registered claims and the local-time conversions.
  4. Remember the signature is not verified and the token is never uploaded.

How it works

The three-part JWT structure

A JWT is three dot-separated parts: the header (declaring the signing algorithm alg and type typ), the payload (business claims) and the signature. All three are base64url-encoded, so the JSON can be decoded locally without any key.

Why the signature isn't verified

Verifying the signature requires the matching key or public key: HMAC needs the secret, RSA and ECDSA need the public key — none of which belong on a web page, and this tool doesn't fetch keys from the network. So it guarantees "structurally valid, decodable" only, never "untampered" — treat the output as a content preview, not a security verdict.

Reading exp / nbf / iat

iat is the issued-at time, nbf the not-before time, exp the expiry — all Unix epoch seconds. The tool displays them in your local timezone with the raw seconds in parentheses for aligning with server logs.

The signature segment and alg=none

The signature segment shows length only, with no validation. alg=none means unsigned with an empty third part; such tokens are forgeable by anyone and belong only in fully trusted internal debugging — production servers must reject them.

Parsing rules: a JWT is three base64url segments (RFC 7519), and an empty signature segment corresponds to alg=none. exp / iat / nbf are Unix epoch seconds displayed in your local time zone; clock skew is not checked and the signature is not verified.

Code example

JavaScript Decoding a JWT in Node 

// Node 15+ supports base64url directly
const [h, p] = token.split(".");
const header = JSON.parse(Buffer.from(h, "base64url"));
const payload = JSON.parse(Buffer.from(p, "base64url"));

// Convert the expiry timestamp
console.log(new Date(payload.exp * 1000));

// Note: this only decodes — it does not verify the signature; use jwt.verify() from jsonwebtoken on the server

Shell Taking the payload apart on the command line 

# The payload is the second segment; base64url omits padding, so pad it before decoding
PAY=$(echo "$TOKEN" | cut -d. -f2)
case $((${#PAY} % 4)) in 2) PAY="${PAY}==";; 3) PAY="${PAY}=";; esac

echo "$PAY" | tr "_-" "/+" | base64 -d | jq .

FAQ

Does parsing a JWT upload the token?

No. Decoding and time conversion happen entirely locally; the token isn't uploaded, isn't written to localStorage, and this tool deliberately has no history section. Still: never paste a real production token into any online tool, local or not.

Why isn't the signature verified?

Verification needs the secret (HMAC) or public key (RSA/ECDSA), and putting those on a web page amounts to leaking them; this tool also doesn't fetch public keys online. It can decode and check structure, but cannot prove the token is untampered.

It says "expired" — can the token still work?

exp is only what the token claims. A server that validates correctly rejects it after exp; but if the server skips validation or has clock skew, it might still be accepted. Treat "expired" as dead either way.

What's the difference between iat, nbf and exp?

iat is when the token was issued, nbf when it becomes valid, exp when it expires — all epoch seconds. Shown in local time with raw seconds in parentheses so you can line them up against server logs.

Why is the signature segment sometimes empty?

alg=none means no signature, leaving the third part empty. Anyone can forge such tokens; they belong only in fully trusted internal debugging, and production servers must reject alg=none explicitly.

Can I trust the alg in the header?

No. alg is self-declared; an attacker can change it to none or swap algorithms to bypass verification (the algorithm-confusion attack). Servers should verify with their own configured algorithm, never with whatever the token claims.

Why doesn't the payload show the user info I expected?

Payload fields are decided by the issuer. The JWT standard defines only seven registered claims — iss, sub, aud, exp, nbf, iat, jti; business fields like name and role are custom claims. This tool lists every decoded field as-is.

Does it support JWE (encrypted tokens)?

No. JWE has five parts (header.encrypted-key.IV.ciphertext.tag) and the content is itself encrypted; this tool handles only three-part JWS. A five-part input is reported as a format error.