JWT decoder
Decode a JWT to inspect its header, payload, and claims — without sending it anywhere.
Paste any JWT below. The header and payload are decoded and pretty-printed instantly. Time-based claims (iat, exp, nbf) are shown as human-readable dates with expiry status.
JWT decoder input
JWT structure
A JWT consists of three base64url-encoded parts separated by dots: header.payload.signature. The header identifies the token type and signing algorithm. The payload carries the claims — assertions about the subject plus any custom data the issuer includes. The signature is a cryptographic hash of the header and payload, signed with a secret or private key.
Base64url is a variant of base64 that uses -
instead of + and
_ instead of
/, making it safe for use in URLs
and HTTP headers without percent-encoding. Decoding the header and payload
requires no secret — the signature is the only part that proves authenticity.
About this tool
This tool decodes JWT (JSON Web Token) strings into their component header, payload, and signature sections. It base64url-decodes and pretty-prints the header and payload JSON, and interprets standard time-based claims (iat, exp, nbf) as human-readable timestamps with expiry status. Everything runs client-side — no token is transmitted to a server. The signature section is displayed raw since signature verification requires the secret key.
Frequently asked questions
What is a JWT?
A JSON Web Token is a compact, URL-safe format for transmitting claims between parties. A JWT has three dot-separated base64url-encoded sections: a header that identifies the signing algorithm, a payload that carries the claims (assertions like user ID, role, and expiry), and a signature that lets the recipient verify the token was issued by a trusted party and hasn't been tampered with. JWTs are most commonly used for authentication — a server issues a signed token after login, and the client includes it in subsequent requests to prove identity without another round-trip to the database.
Is it safe to paste a JWT here?
Decoding runs entirely in your browser using JavaScript. The token is not sent to any server. That said, a JWT may contain sensitive claims (user ID, email, roles). For tokens from production systems, be aware of your environment — browser extensions and page scripts can read clipboard and input field contents. For debugging tokens that don't contain sensitive personal data, or tokens issued by a dev/test system, pasting here is safe.
Why can't this tool verify the JWT signature?
Signature verification requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA/EC algorithms like RS256). This tool doesn't have access to your keys, and asking you to paste them alongside the token would be a serious security risk. If you need to verify a signature, use your application's authentication library directly, or the server-side jwt.verify() call. This tool is for inspecting claims and debugging token contents — not for security decisions about whether to trust a token.
What does the exp claim mean?
The exp (expiry) claim is a Unix timestamp (seconds since 1 January 1970 UTC) after which the token must not be accepted. When exp is in the past, the token is expired and should be rejected by any standards-compliant implementation. The iat (issued at) claim records when the token was created, and nbf (not before) records the earliest time at which the token is valid. All three are Unix timestamps and are interpreted as human-readable dates below.