JWT Decoder

This JWT decoder splits a JSON Web Token into its header, payload and signature and decodes each one. Standard claims are humanised — expiry and issue times become real dates with a valid or expired badge — and HMAC signatures can be verified with your secret, without the token ever leaving the page.

How to use JWT Decoder

  1. Paste your JWT into the input box, or press “Load example” to try a sample token.
  2. Read the decoded header and payload; the algorithm and token type appear as badges.
  3. Check the claims table for exp, iat and nbf rendered as absolute dates plus relative time.
  4. To verify an HS256, HS384 or HS512 signature, paste the shared secret and read the verdict.
  5. Copy any section, or download the decoded payload as JSON.

About JWT Decoder

A JSON Web Token is three Base64URL-encoded parts joined by dots: a header describing the signing algorithm, a payload of claims, and a signature over the first two. Because the first two parts are merely encoded, anyone can read them — which is precisely why a decoder is a daily-use tool. Nine times out of ten a failing login is explained by one line in the payload: an exp in the past, an aud that does not match the API, or an iss pointing at the wrong tenant.

This decoder handles the reading and the arithmetic. Registered claims from RFC 7519 are labelled and explained, and the three time claims are converted from NumericDate seconds into an absolute local timestamp plus a relative phrase such as "expired 14 minutes ago", with a valid or expired badge derived from your device clock. The header’s alg is surfaced as a badge too, since spotting an unexpected none or a downgraded algorithm is a security check worth doing by eye.

Signature verification is offered for the HMAC family. Paste the shared secret and the tool imports it with crypto.subtle.importKey and verifies the signature over the exact header.payload bytes, so a mismatch tells you the secret is wrong or the token was tampered with. RSA and ECDSA tokens need the issuer’s public key from a JWKS endpoint, and because this page makes no network calls it will say so plainly rather than pretend. Everything else — decoding, claim analysis, expiry — works identically for all algorithms.

Frequently asked questions

Is my token sent to a server?

No. Decoding and signature verification run entirely in your browser using the Web Crypto API. That matters more here than for most tools: a JWT is a live credential, and pasting one into a site that posts it to a backend should be treated as a leaked secret.

Is a JWT encrypted?

A standard signed JWT (JWS) is not. The header and payload are only Base64URL-encoded, so anyone holding the token can read every claim inside it. The signature guarantees the token has not been altered — it does not keep the contents private. Never put secrets in a payload.

Why can it verify HS256 but not RS256?

HMAC algorithms use one shared secret, which you can paste. RS256, RS384, ES256 and friends are asymmetric: verification needs the issuer’s public key, usually fetched from a JWKS endpoint. This tool makes no network requests, so it decodes those tokens fully but reports their signature as unverified.

What do exp, iat and nbf mean?

exp is the expiry time, iat the time the token was issued and nbf the "not before" time it becomes valid. All three are NumericDate values — seconds since the Unix epoch, not milliseconds — which is why a token dated 1970 usually means someone passed a JavaScript timestamp straight through.

My token is expired but the API still accepts it. Why?

Most servers allow a small clock-skew tolerance, typically 30 to 300 seconds, and some validate only the signature. The badge here compares exp against your device’s clock with no tolerance, so a token that has just lapsed shows as expired even if a lenient server would still take it.

Does it work with tokens from Auth0, Firebase, Cognito or Okta?

Yes — they all issue standard JWTs. Custom and namespaced claims are shown alongside the registered ones, and the claims table labels the ones defined in RFC 7519 so provider-specific extras are easy to spot.

Related tools

All developer tools · Browse all 56 free tools →