Paste a JWT
Add a compact token containing header, payload, and signature segments.
Decode JSON Web Token headers and payloads locally. A jwt token viewer for inspecting claims at a glance, with no upload and no signature check.
Three simple steps, with your content kept on your device.
Add a compact token containing header, payload, and signature segments.
Read the Base64URL header and payload as formatted JSON.
Review algorithm, issue time, expiration, and payload values.
Fast, focused, and made to be clear on every screen.
View decoded token sections with readable indentation.
See common algorithm, issued-at, and expiration values.
Sensitive token text remains inside your browser.
A JWT, or JSON Web Token, is a compact token used to pass claims between parties — most often to identify a user in an API session. It looks like three dot-separated Base64URL segments, each hiding a JSON object.
The three parts are the header, which describes the signing algorithm; the payload, which carries the claims; and the signature, which proves the token was produced by whoever holds the secret key.
The decoder splits the token at the dots, decodes the header and payload from Base64URL, and presents them as readable JSON. The claim summary highlights common values such as the algorithm, issued-at, and expiration times.
This is a parser and debugger: it reveals what the token contains. Sensitive token text remains inside your browser and is never uploaded.
Decoding only reveals the header and payload. Anyone can create or modify an unsigned payload, so a decoded JWT is not trustworthy on its own.
Signature verification requires the correct key and the expected algorithm, which this tool does not perform. Trust claims only after proper signature, issuer, audience, and time validation on your side.
The header states the type and algorithm, typically HS256 or RS256. The payload holds the claims — subject, issuer, audience, and expiry. The signature is a hash of the first two segments signed with the secret key.
Inspecting all three parts with a JWT parser makes it easy to understand why a token was rejected: an expired exp claim, a wrong audience, or an unexpected algorithm all show up at a glance.
Tokens may contain sensitive data, which is why this decoder works locally and never uploads the token. Treat decoded claims the same way you would treat the raw token.
This tool handles the common three-part signed JWT format, not encrypted JWE tokens, which use a different structure.
When an API rejects a request, the JWT token is often the first thing to inspect. Decoding it shows the expiry time, the issuer, the audience, and the algorithm — the fields that typically cause 401 responses.
A JWT debugger workflow is straightforward: paste the failing token, read the decoded claims, and check whether exp is past, aud matches the API, or the algorithm differs from what the server expects.
Tokens can carry user identifiers and other sensitive claims, so decode them in a private tab or local tool rather than pasting them into shared services. This decoder runs entirely in your browser for that reason.
Never paste a production token into a third-party website. Local decoding gives you the same insight without exposing the token to a server.
The most common claims are exp (expiration), iat (issued at), iss (issuer), aud (audience), sub (subject), and jti (unique token ID). Decoding a token shows these values as readable JSON, making the token's meaning obvious.
A token that fails validation usually fails on one of these: exp is in the past, aud does not match the API, or iss differs from the expected issuer.
During development, tokens are generated and rejected constantly. A fast local decoder turns a mysterious 401 into a clear explanation: the token expired five minutes ago, or the algorithm does not match the server configuration.
This workflow is exactly what the tool is built for — paste, decode, read the claims, fix the cause, and move on.
JWTs are self-contained: the claims travel inside the token, so a server can read them without a database lookup. Opaque tokens are random strings that require a server-side store to resolve.
This distinction matters when you decode a token and see claims in plain JSON — that transparency is the main reason developers reach for a JWT decoder during API work.
No. Decoding only reveals the header and payload. Signature verification requires the correct key and expected algorithm.
Not by itself. Anyone can create or modify an unsigned payload. Trust claims only after proper signature, issuer, audience, and time validation.
No. This tool handles the common three-part signed JWT format, not encrypted JWE tokens.