TK TaskKit
Developer Tools

JWT Decoder

Decode JSON Web Tokens, inspect claims, and check expiry without uploading the token.

DecodeEncode
Token
Decoded

Paste a JWT to inspect its header, payload, and registered claims.

HS256 token signed with the secret "taskkit-demo-secret" — switch to Verify mode and paste the secret to test verification.

Inputs stay on this device. Every developer tool on TaskKit runs entirely in your browser. Tokens, payloads, and pasted text are not transmitted to TaskKit servers or third parties.

What this tool does

This JWT decoder splits a JSON Web Token into its three parts — header, payload, and signature — and shows you the decoded contents along with the registered claims (iss, sub, aud, exp, iat, nbf, jti). The validity window is computed from exp and nbf so you can see at a glance whether a token is in date.

It also offers signature verification for the algorithms most APIs actually use: HS256/384/512 with a shared secret, RS256/384/512 and PS256/384/512 with an RSA public key, ES256/384/512 with an EC public key, and EdDSA with an Ed25519 key. Public keys can be pasted as a JWK, a full JWKS (TaskKit picks the right key by matching the token's kid), a PEM SPKI block, a PEM PKCS#1 RSA public key, an X.509 certificate (the public key is extracted automatically), or — for EdDSA — as 64 hex chars or 43 base64url chars. If the token's header contains an x5c array (an inline X.509 certificate chain), the leaf cert is used automatically when the key field is empty.

When you'd use it

  • Inspecting a token returned by your auth server during local development.
  • Confirming that a third-party token's claims match what your client expected.
  • Verifying that a refreshed token is signed with the same key as before.
  • Checking expiration when something stopped working at exactly midnight UTC.

How it works

Decoding is just Base64URL — the JWT spec uses URL-safe Base64 with padding stripped. Header and payload are JSON; the signature is raw bytes. Verification uses crypto.subtle.verify, the browser's built-in WebCrypto API, with the algorithm pulled from the header. EdDSA goes through @noble/ed25519 (also browser-only) since WebCrypto's Ed25519 support is still patchy across browsers.

Key input is permissive on format. Symmetric keys (HS*) are imported as raw bytes or as a JWK. Asymmetric keys (RS/PS/ES) are accepted as JWK, JWKS (the token's kid selects the right key — single-key sets are used directly), PEM SPKI (BEGIN PUBLIC KEY), PEM PKCS#1 RSA public key (BEGIN RSA PUBLIC KEY), or an X.509 certificate (BEGIN CERTIFICATE) — TaskKit walks the cert with a small in-house ASN.1 reader to pull out the embedded SubjectPublicKeyInfo. EdDSA keys can be a JWK, a JWKS, an SPKI PEM, 64 hex chars, or 43 base64url chars.

Nothing about this tool is server-side. The token never leaves your browser, the key never leaves your browser, and there is no telemetry on either. If you copy-paste a production token to debug something, your auditor will not see a request to taskkit.net carrying that token.

Notes

Why is "alg: none" rejected even when the token validates? Because no real-world JWT should ever use alg: none. It's a known attack vector: if your verifier accepts none, an attacker can strip the signature and forge any payload. We surface it as an error rather than silently passing.

Can I verify a Microsoft / Google / Auth0 token? Yes — fetch the issuer's JWKS (e.g. https://login.microsoftonline.com/common/discovery/v2.0/keys) and paste the whole JSON document into the key field. TaskKit reads the token's kid header and picks the matching JWK automatically; no manual lookup needed.

HS256 vs RS256 — which should I be using? RS256 (or ES256) for anything an external party will verify, since they only need the public key. HS256 is fine for service-to-service when both sides hold the same secret.

My token has an x5c header — does that mean I'm trusting the embedded certificate? TaskKit will use the leaf cert from x5c to verify the signature when you don't paste a key, so you can confirm the token's contents weren't tampered with. It does not validate the chain back to a CA — that requires trust roots and is out of scope here. The result chip shows "verified with the x5c certificate from the token header (chain not validated)" so you don't mistake it for an end-to-end trust verdict.

Related tools