Decoding is not verification. Without a secret this only reads the token; with one, HS256/384/512 signatures are checked via WebCrypto in the browser. RS/ES tokens need a public key and are not verified here.
Decoding is not verification. Without a secret this only reads the token; with one, HS256/384/512 signatures are checked via WebCrypto in the browser. RS/ES tokens need a public key and are not verified here.
A JWT is a credential. Pasting one into a website that decodes it server-side hands someone a session, which is why this decoder runs entirely in the page: the token is split and base64url-decoded locally, and if you supply the signing secret, the HMAC signature is verified with the browser's own WebCrypto. Expiry and not-before claims are worked out for you in plain language.
Both halves decoded and pretty-printed, with UTF-8 claims intact.
exp, iat and nbf are shown as real dates plus "in 42 minutes" or "3 days ago".
Supply the secret and the signature is checked with WebCrypto, in the page.
A JWT is a live credential. This one is decoded locally and goes nowhere near a server.
No, and this is the one page where that matters most. Decoding and verification both happen in your browser. There is no backend to receive it.
No. Those are signed with a private key and verified with the matching public key, which this tool does not ask for. RS/ES tokens are decoded and clearly reported as unverified.
No. Anyone can read a JWT — the payload is only base64-encoded, not encrypted. Only a signature check with the right key proves it is genuine, which is what the secret field is for.