JWT guide: decode, verify and sign JSON Web Tokens
A practical guide to JWTs — how they're structured, what every claim means, how to read the time claims, the difference between decoding and verifying, how to check a signature with a secret or public key (PEM, JWK or JWKS), and why it's safe to do this locally.
Open the JWT Decoder & Encoder →What this tool does
The JWT Decoder & Encoder splits a token into its three
parts, Base64URL-decodes the header and payload into colour-highlighted JSON, explains every
claim in plain English, turns the time claims into readable dates (hover any timestamp to see
local time, UTC, ISO 8601, the relative time and the raw Unix value), flags problems like
expiry or an unsecured alg: none, and verifies the signature. It can also build
and sign brand-new tokens. Everything runs in your browser.
How a JWT is structured
A JWT is three Base64URL sections joined by dots: header.payload.signature.
The header names the algorithm (e.g. HS256) and optionally a key id (kid), the
payload holds the claims, and the signature is computed over the first two parts with a
secret or private key. In the tool, each part is colour-coded so you can see the boundaries
at a glance.
Decoding vs verifying
Decoding just reveals the header and payload — anyone can do it, so the payload is not secret and must never hold passwords or sensitive data. Verifying recomputes the signature with the secret (or key) to prove the token is authentic and unmodified. A decoded-but-unverified token tells you nothing about whether it can be trusted.
Standard claims
ississuer,subsubject,audaudience — who issued the token, who it's about, and who it's for.iatissued-at,nbfnot-before,expexpiry — shown as dates with a live "expires in / expired" status. Hover a value for the full breakdown across time zones and formats.jtia unique token id, plus OIDC extras likeazp,scopeandnonce— all annotated in the claims table.
Verifying the signature
The tool reads the algorithm from the header and shows the right input automatically:
- HMAC (HS256/384/512) — paste the shared secret. Tick the box if your secret is Base64URL-encoded.
- RSA, RSA-PSS and ECDSA (RS/PS/ES 256/384/512) — paste the public key as
a PEM
PUBLIC KEY, a PEM X.509CERTIFICATE(the public key is extracted automatically), a JWK, or a full JWKS. With a JWKS the correct key is selected using the token'skid. You can also fetch a JWKS by URL — only that endpoint is contacted, and your token is never sent.
Encoding and signing
Switch to Encode & Sign to craft a token: pick an algorithm, edit the
header and payload (one-click buttons add iat, nbf and
exp), then sign with a secret or private key. No key handy? Generate an RSA or
EC key pair in-browser — the private key signs and the public key is shown for you to share
for verification. These tokens are for testing and learning; never paste production private
keys on a shared machine.
Privacy
Tokens often grant access, so a server-side decoder is a real risk. Here, decoding, verification, key generation and signing all run entirely in your browser via the Web Crypto API — nothing is uploaded. The only optional network request is fetching a JWKS URL you type, and even then your token stays local.
FAQ
Is decoding the same as verifying?
No — decoding reads the token; verifying checks the signature with the secret or key.
Which algorithms are supported?
HS256/384/512, RS256/384/512, PS256/384/512 and ES256/384/512, for both verifying and signing.
Is my token sent anywhere?
No — it all runs locally in your browser. Only a JWKS URL you choose to fetch is contacted.
Should I paste production tokens?
It's local and safe, but treat real tokens and private keys with care on shared machines.
Ready to try it? Open the JWT Decoder & Encoder →