JWT Decoder

Frequently Asked Questions

Is it safe to paste my JWT here?

Safer than most online decoders, because this one runs entirely in your browser: pasting and decoding fire no network request, which you can confirm in DevTools → Network. That said, for production tokens carrying an active session identifier the safest route is always a local CLI or your IDE's JWT extension. Any valid token pasted into any web page is a potential credential leak if the page or a browser extension is compromised.

Does it verify the signature?

No, this tool only decodes. Signature verification needs the signing secret (HS256) or the issuer's public key (RS256 / ES256), and neither belongs in a random web tool. Decoding is one-way reading; verification is a separate step, best done server-side or with a dedicated library (jose, jsonwebtoken, pyjwt).

What claims are shown?

Every claim in the payload, with special highlighting for the standard registered ones: iss (issuer), sub (subject), aud (audience), exp (expiration, rendered as a human date plus an expires-in badge), iat (issued-at), nbf (not-before), jti (token ID). Custom claims (roles, tenant, email, scopes) are listed below in their original order.

Why does my token look like it has three parts separated by dots?

Because a JWT has exactly three parts: header.payload.signature, each Base64URL-encoded. The header and payload decode to JSON; the signature is a binary MAC or signature that cannot be decoded to readable text. If your token has more or fewer dots it is not a standard JWT, possibly a JWE (the encrypted variant, which this tool does not support).

My JWT has "alg":"none", is that dangerous?

Yes, historically a major vulnerability. alg:none means the token is unsigned, and any application that accepts it blindly will trust forged tokens. Modern libraries reject alg:none by default. Seeing it in a token from a production service is a red flag: the issuer should never emit unsigned tokens.

What's the difference between HS256 and RS256?

HS256 is symmetric (HMAC with a shared secret): fast, but anyone who can verify can also sign. RS256 is asymmetric (an RSA key pair): the issuer signs with the private key and consumers verify with the public key. OAuth and OpenID Connect use RS256 (or ES256) precisely because the public key can be distributed safely. Use HS256 only for internal same-service tokens where a shared secret makes sense.

How do I check if my JWT is expired?

Read the badge: green "expires in 23 minutes" while the token is still valid, red "EXPIRED 2 hours ago" once it is not. The badge comes from the `exp` claim, a Unix timestamp in seconds, and the token is expired when `exp < Date.now() / 1000`. A token with no `exp` claim never expires, which is usually a misconfiguration since most issuers should set one.

Can I decode a JWT in Node, Python, or with curl?

Yes, in one line each. Node: `Buffer.from(token.split('.')[1], 'base64url').toString()`. Python: `import base64,json; json.loads(base64.urlsafe_b64decode(token.split('.')[1] + '=='))`. Bash: `echo $TOKEN | cut -d. -f2 | base64 -d | jq` (add `=` padding if needed). All three decode the payload only; for verification use jose (Node), pyjwt (Python) or a CLI like jwt-cli.

What's the difference between JWT and JWE?

A JWT (JSON Web Token, RFC 7519) is signed: the payload is Base64-encoded and readable by anyone, since signing only proves who issued it. A JWE (JSON Web Encryption, RFC 7516) is encrypted: the payload is unreadable without the decryption key. JWTs have three parts (header.payload.signature), JWEs have five (header.encryptedKey.iv.ciphertext.tag). This tool decodes JWTs only; a JWE needs the recipient's private key and cannot be opened by a generic web tool.