DT Dev Tools

JWT Decoder

Decode JWT header and payload, see exp/iat as readable dates with an expired badge, and verify HS, RS, PS, ES and EdDSA signatures locally in your browser.

πŸ”’ Runs entirely in your browser β€” nothing is uploaded

Verify signature

HS256/384/512 need the shared secret; RS, PS, ES and EdDSA need the public key as PEM (-----BEGIN PUBLIC KEY-----) or JWK. Verification runs with Web Crypto in this tab β€” avoid pasting production secrets into any website.

Was this tool useful? Rate it:

What JWT Decoder does

JWT Decoder splits a JSON Web Token into its three dot-separated segments, base64url-decodes the header and payload, and pretty-prints those JSON objects. It is useful when debugging login flows, API authorization headers, OAuth callbacks, refresh behavior, and tests that depend on claims such as subject, issuer, audience, issued-at time, and expiration time. Every claim is listed in a table with its standard meaning, and time claims are converted for you.

The tool can also verify the signature. HMAC tokens (HS256, HS384, HS512) need the shared secret, which you can paste as plain text or Base64. Asymmetric tokens (RS256, PS256, ES256, their 384/512 variants, and EdDSA) need the issuer's public key as a PEM PUBLIC KEY block or a single JWK from the provider's JWKS endpoint. A green result means the token was signed with that key and has not been modified; a red result means the key is wrong or the token was tampered with. Tokens that use alg: none are flagged as unsigned.

Private browser-based workflow

All processing happens with in-browser JavaScript and the Web Crypto API. The tool does not upload your tokens, secrets, keys, URLs, or generated values to a server, and it does not require an account. That privacy model is important because small utilities often receive real API responses, configuration samples, logs, authentication data, or customer-shaped examples during troubleshooting. Keeping the work local reduces risk and also makes the tool feel instant because there is no network round trip.

Reading the decoded output

Standard claims you will often see are iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before) and iat (issued at). The time claims are Unix timestamps in seconds; the claim table shows each one as an ISO 8601 UTC date plus a relative time such as "in 2 hours" or "3 days ago", and the status line tells you at a glance whether the token is valid, expired or not valid yet.

The decoder expects exactly three dot-separated segments; anything else produces a decode error. Encrypted tokens (JWE) have five segments and cannot be read without the key, and a segment that is not valid base64url JSON will also fail. A valid signature proves who issued the token, but your application must still check the issuer, audience and expiry. Treat live tokens like passwords: although nothing leaves your browser here, avoid pasting production tokens into tools you do not trust or sharing decoded output publicly.

How to use

  1. Paste tokenAdd a JWT with three dot-separated segments; a leading Bearer prefix is ignored.
  2. Read the claimsReview the header, payload, claim table and the expiry status.
  3. Verify the signaturePaste the secret or public key and click Verify signature.

Frequently asked questions

Can it verify the signature?
Yes. Paste the shared secret for HS256/384/512, or the public key as PEM or JWK for RS, PS, ES and EdDSA tokens. Verification uses the browser's Web Crypto API.
How do I know if a token is expired?
The decoder converts exp, nbf, iat and auth_time to readable UTC dates with relative times and shows whether the token is valid, expired or not yet valid.
Can I decode production tokens?
It runs locally, but avoid sharing or saving sensitive tokens, and never paste private keys β€” only the public key is needed for verification.