JWT Decoder — Free Online JSON Web Token Inspector
Decode and inspect JWT tokens instantly. View the header, payload, signature, and claims of any JSON Web Token, read every timestamp as a real date, and see at a glance whether the token has expired. Fully client-side — tokens and secrets are never sent anywhere.
What is a JWT? A JSON Web Token is three Base64Url-encoded segments joined by dots — header.payload.signature — defined by RFC 7519. The header names the signing algorithm, the payload carries the claims, and the signature covers the first two segments so a server can detect tampering. Base64Url is encoding, not encryption: anyone holding the token can read every claim in it, which is why a JWT should never contain a secret.
How to Use the JWT Decoder
-
Paste the token — Anything with three dot-separated segments works — copied from an
Authorization: Bearerheader, a cookie, a log line or an API response. Decoding happens on every keystroke. If you have no token to hand, Sample Token mints a fresh HS256 one with realistic claims. -
Read the header for the algorithm — The Algorithm card shows the
algvalue. This is the first thing to check when a token is rejected: a service configured for RS256 will refuse an HS256 token outright, whatever the claims say. -
Check the status and expiry cards — Status compares the
nbfandexpclaims against your computer's clock, in that order, and reports Not Yet Valid, Valid, Expired, or No exp claim. The comparison is exact, with no allowance for clock skew, so a token a few seconds either side of the boundary can read differently here than on the server. -
Work through the claims table — Every header and payload key is listed, with registered claims given readable names —
issas Issuer,subas Subject. Timestamp claims are rendered as a local date plus a relative phrase, so1735689600becomes a date you can actually compare against your logs. -
Compare the payload against what the API expected — Most 401 and 403 responses come down to a mismatch you can see here: an
audnaming a different API, a missing scope or role, or anisspointing at the wrong tenant. Open the raw payload panel next to the claims table to check the exact spelling and case of custom claims. - Copy the piece you need — Each of the header, payload and signature panels has its own Copy button, so you can paste the decoded payload straight into a bug report without hand-trimming the token string.
How a JSON Web Token Is Built
A JWT is not a container format so much as a recipe. The issuer writes two small JSON objects, encodes each with Base64Url, joins them with a dot, signs that exact string, and appends the encoded signature:
token = base64url(header) + "." + base64url(payload) + "." + base64url(signature)
Base64Url is ordinary Base64 with two substitutions and no padding: + becomes -,
/ becomes _, and trailing = characters are removed, so the result survives
being placed in a URL or a header. This decoder reverses those substitutions, restores the padding, runs
atob and then decodes the bytes as UTF-8 — which is why claims containing accented characters or
emoji come out correctly rather than as mojibake.
The signature is computed over the first two segments as they appear in the token, not over the JSON you see after decoding. That detail explains a class of bugs: re-serialising a payload changes key order and whitespace, which changes the signed string, which invalidates the signature. A JWT cannot be edited and re-signed without the key, and that is the entire point of the format.
Registered claims
RFC 7519 reserves seven claim names. Every one of them is optional, so a token missing exp is
technically valid and practically dangerous — it never stops working. Time claims use NumericDate: seconds,
not milliseconds, since 1 January 1970 UTC.
| Claim | Name | What it means in practice |
|---|---|---|
iss | Issuer | Who minted the token. A verifier should accept only issuers it knows. |
sub | Subject | Who or what the token is about, usually a stable user id rather than an email. |
aud | Audience | Which API is meant to accept it. A string or an array; the wrong value is a very common 401. |
exp | Expiration Time | Reject at or after this second. Short lifetimes limit the damage of a leaked token. |
nbf | Not Before | Reject before this second. Usually set to issue time, and a source of clock-skew failures. |
iat | Issued At | When it was created. Useful for age policies and for spotting a stale cached token. |
jti | JWT ID | A unique id, so a token can be recorded and refused on replay. |
Anything else in the payload is a public or private claim. OpenID Connect adds a familiar set —
nonce, at_hash, auth_time, acr, amr, plus profile
claims such as email and preferred_username — and this decoder gives those readable
labels too. Vendor-specific claims like scope, roles, permissions,
tenant and gty are shown under their own names.
Signing Algorithms and What They Imply
The alg header decides who is able to create a valid token. Symmetric algorithms use one shared
secret for both signing and checking, so every service that can verify a token can also forge one. Asymmetric
algorithms split those abilities: the issuer holds a private key, and verifiers need only the public key, which
is why public identity providers publish a JWKS endpoint and use RS256 or ES256.
alg | Mechanism | Key model | Typical use |
|---|---|---|---|
| HS256 / HS384 / HS512 | HMAC with SHA-2 | One shared secret | Internal services that already share a secret |
| RS256 / RS384 / RS512 | RSA PKCS#1 v1.5 | Private signs, public verifies | The default for most OAuth and OIDC providers |
| PS256 / PS384 / PS512 | RSA-PSS | Private signs, public verifies | Newer RSA deployments; smaller install base |
| ES256 / ES384 / ES512 | ECDSA | Private signs, public verifies | Much shorter signatures than RSA at similar strength |
| none | No signature at all | None | Valid per the spec, and a red flag in any real token |
Two classic attacks both start in the header. In the alg: none attack, an attacker strips the signature and sets the algorithm to none, hoping the verifier trusts the header. In algorithm confusion, an RS256 token is re-signed as HS256 using the issuer's public key as the HMAC secret, which succeeds if the verifier picks its algorithm from the token instead of from its own configuration. The defence for both is the same: pin the expected algorithm in your verification code and never read it from the token.
What This Decoder Can and Cannot Tell You
Decoding and verifying are different operations, and only the first is something a web page can do reliably. This tool reads the token: it splits the three segments, decodes the header and payload, formats the claims and compares the time claims against your clock. All of that is deterministic and needs no key.
- Signature checking here is not dependable. The HMAC comparison on this page reports a mismatch even when the secret is correct, so an "Invalid" verdict tells you nothing about the token. Verify signatures server-side with a maintained JWT library, or with your provider's introspection endpoint — never conclude a token is forged from this panel.
- The token type is a guess. It is inferred from which claims are present:
gtyreads as a refresh token,nonceorat_hashas an ID token,scopeorrolesas an access token. Because almost every token carriestyp: "JWT"in its header, anything without those markers falls through to "Access Token". Trust your provider's documentation over this label. - Expiry is judged by your clock. There is no leeway window, so a laptop whose time is a minute off will disagree with the server about a token near its boundary. If a token looks freshly expired, check your system clock before you blame the issuer.
- Nothing is uploaded, but the URL holds your input. Decoding runs entirely in the page. The token and the secret field are also mirrored into the address bar so the tab can be reloaded — which means they land in browser history and in anything you paste that URL into. Clear both fields before sharing the link.
Do not paste a production signing secret into this or any other web page. A leaked HMAC secret lets anyone mint tokens for any user of that system, and there is no way to tell afterwards. If you need to test a real key, do it locally with a JWT library. Treat the tokens themselves with the same care: a bearer token in a support ticket is a live credential until it expires.
Frequently Asked Questions
A JWT has three Base64Url-encoded parts separated by dots: header.payload.signature. The header specifies the algorithm (like HS256 or RS256), the payload contains the claims (data), and the signature verifies the token hasn't been tampered with.
Not reliably. The HMAC check on this page reports a mismatch even when the secret is right, so treat its verdict as inconclusive rather than as evidence a token was tampered with. Verify properly on the server with a maintained JWT library, which also checks iss, aud and expiry against your own configuration. RSA and ECDSA tokens cannot be checked here at all, since they need the issuer's public key from its JWKS endpoint.
The exp claim is a Unix timestamp in seconds, and the token is expired once your clock passes it. Common causes are a token cached longer than its lifetime, a refresh flow that silently failed, or a clock difference between your machine and the issuer — this page applies no skew allowance, so a token within a minute of its boundary can read as expired here and be accepted by the API, or the reverse.
HS256 signs with one shared secret, so everyone able to verify a token is also able to mint one — workable inside a trust boundary, dangerous across one. RS256 signs with a private key and verifies with the matching public key, so verifiers need nothing secret and the issuer alone can create tokens. Public identity providers publish their public keys at a JWKS URL and use RS256 or ES256; internal service-to-service setups often stay on HS256.
By a heuristic over the claims, checked in this order: gty means a refresh token; nonce, at_hash or c_hash mean an ID token; scope, scp, roles or permissions mean an access token; otherwise a header of typ: "JWT" also reads as an access token. Since nearly every JWT carries that header, most unrecognised tokens are labelled access tokens. It is a hint, not a determination.
No network request carries it. Splitting, Base64Url decoding and claim formatting all run in JavaScript in your tab, and the page works offline once loaded. The one thing to know is that your input is mirrored into the page URL so the tab can be bookmarked and reloaded — that puts the token, and anything typed in the secret field, into your browser history. Clear the boxes before sharing the link.
No, and no decoder can. The signature is computed over the exact Base64Url text of the first two segments, so changing a single character invalidates it, and producing a new signature requires the issuing key. Use the JWT Encoder to build a fresh test token with a secret of your own choosing, rather than trying to modify one you were issued.
Only data the holder is allowed to see. Base64Url is encoding, not encryption — paste any token into this page and every claim is legible without a key. Anything genuinely confidential belongs behind a lookup on your server, or in a JWE, which is a separate encrypted format. Also keep tokens small: they travel in a header on every request, and large payloads cost bandwidth on all of them.
The format check is strict: exactly three dot-separated segments. Truncation at a line wrap when copying from a terminal or a log viewer is the usual cause, as is copying a token with the word Bearer still attached, or one that was URL-encoded so its dots or dashes changed. If the segment count is right but decoding still fails, the header or payload is not valid JSON — often the sign that only part of the token was copied.
Use Cases
Inspecting JWT Claims
Decode JWT tokens to view all claims including user ID, roles, and custom data in a readable format.
Debugging Auth Tokens
Quickly identify why authentication tokens are failing by examining their contents and expiration.
Verifying Token Expiration
Check if JWT tokens are expired or still valid to troubleshoot authentication issues.
Understanding OAuth Payloads
Analyze OAuth token payloads to understand what data is being passed between services.
Checking Header Algorithms
Verify the signing algorithm used in JWT headers to ensure proper security configuration.