The JWT decoder uses jwt-decode to parse a token's header and payload locally in the browser and shows the iat, nbf and exp numbers as dates and relative times from Unix seconds. It only decodes and never verifies the signature, so “it parses” or “exp has not passed” does not mean the token is valid or trustworthy.

1. 01Paste a JWT; a Bearer prefix is allowed.
2. 02Read the three-part colouring, and the header and payload JSON.
3. 03If iat, nbf or exp is present, read the local date and relative time together with the expired or not-yet-valid note.
4. 04Copy the structured JSON; verifying a signature has to be done on a server or with a dedicated tool that holds the correct key and algorithm policy.

• The token has to decode as JWT Base64URL structure; a malformed one reports a parse failure.
• It does not compute or verify an HMAC, RSA or ECDSA signature, does not check whether the alg is permitted, and does not validate business claims such as iss, aud or sub.
• iat, nbf and exp are only read as Unix seconds when they are numbers; a string time is not converted automatically.
• The status prefers “expired”, then “not yet valid”, and otherwise shows “valid” from the time claims alone; that is not a cryptographic verification result.
• A JWT payload was only ever encoded, not encrypted, so anyone holding the token can normally read its contents.

The token is decoded in browser memory only and is never sent to a server; production credentials should still not be pasted into an untrusted device.