JWT Decoder
Decode JWT tokens instantly. View header and payload as JSON. See expiration dates in human-readable format.
JSON Web Tokens (JWTs) are the standard way to represent authentication and authorization information in modern web applications. After logging in to a service, your browser typically receives a JWT that it sends with every subsequent request. The server reads the token to know who you are and what you are allowed to do — without needing to query a database on every request.
A JWT is composed of three parts separated by dots: the header, the payload, and the signature. The header specifies the algorithm used to sign the token (e.g., HS256 or RS256). The payload contains claims — JSON key-value pairs encoding information like user ID, roles, expiration time, and issuer. The signature ensures the token has not been tampered with.
This tool decodes the header and payload sections so you can inspect their contents. Common debugging scenarios include checking whether a token has expired (the "exp" claim), seeing which user or subject the token represents ("sub"), verifying the issuer ("iss"), and inspecting custom application claims added by your auth provider.
Note that decoding a JWT is not the same as verifying it. Anyone can decode a JWT — the payload is simply Base64Url-encoded, not encrypted. The signature verification (which requires the secret key) is what ensures the token is genuine. Use this tool for inspection and debugging, not for security checks. All decoding runs locally in your browser.
Registered claim reference
RFC 7519 defines a small set of standard claim names that you will encounter in nearly every JWT. Understanding what each one means — and which ones your server should actually check — is most of what you need to know to debug an auth flow.
- iss (issuer) — the URL or identifier of the service that produced the token. Match it against the issuer you expect; otherwise the token was minted by someone else.
- sub (subject) — the user or entity the token is about. Usually a stable, opaque identifier (not an email).
- aud (audience) — the service or services the token is intended for. Your service should be in this list.
- exp (expiration) — Unix timestamp after which the token is invalid. Reject anything whose
expis in the past, with a small leeway for clock skew. - nbf (not before) — Unix timestamp before which the token must not be accepted.
- iat (issued at) — Unix timestamp of when the token was created.
- jti (JWT ID) — a unique identifier for the token, useful for implementing replay protection.
How this tool handles your token
Everything happens on your device. The decoder splits the token on dots, Base64url-decodes the first two segments, and renders the parsed JSON. The signature segment is displayed as-is because it is a cryptographic value, not printable JSON. No token ever leaves the browser — you can confirm by opening the network tab while using the tool.
When to use a different tool
For signature verification you need access to the signing secret or public key and the full cryptographic library stack for the algorithm the token uses. That is a server-side job; use a well-maintained library (jsonwebtoken in Node, PyJWT in Python, jjwt in Java, golang-jwt/jwt in Go) and configure it with pinned algorithm, issuer, and audience checks. For a conceptual walk-through of the verification pipeline and the attacks that target it, see our article on how JWT verification actually works.