JWT Decoder
Decode a JSON Web Token's header and payload instantly — free, unlimited, in your browser.
- Client-side processing
- Privacy-first
- Unlimited usage
- No account required
- Secure by design
Frequently asked questions
- Does this tool verify the token's signature?
- No. This tool only decodes the header and payload segments — it never verifies a signature or proves the claims are trustworthy. Signature verification requires the issuer's secret or public key, which this tool never asks for or has access to.
- Is my token uploaded anywhere?
- No. Decoding happens entirely in your browser. The token is never sent to a server, never logged, never stored in your recent-tools history, and never placed in the page URL.
- Why does it say "Token structure decoded" instead of "Valid JWT"?
- Because decoding the header and payload only tells you the token is well-formed — it says nothing about whether the signature is genuine. Only the token's issuer, or a verifier with the correct key, can confirm that.
- What does an expired or not-yet-active warning mean?
- The Claims tab compares the token's exp (expiration) and nbf (not before) claims, if present, to the current time and flags tokens that are expired or not yet valid.
- Does it work with a "Bearer" prefix?
- Yes — pasting a full Authorization header value like "Bearer eyJ..." works; the prefix is stripped automatically before decoding.
- Why does a JWT have exactly three segments?
- The JWT specification (RFC 7519) defines a token as header.payload.signature — three Base64URL-encoded parts joined by periods. Anything with a different segment count isn't a standard JWT, even if it superficially looks like one.
- Should I trust the algorithm named in a token's header?
- Not for verification. The alg field is part of the payload an attacker controls when forging a token, so a server should verify against the algorithm it expects for that key — never blindly use whatever alg the token claims (this is the well-known "alg confusion" class of vulnerability).
- Why do access tokens and ID tokens look different?
- Both are JWTs with the same header/payload/signature structure, but OpenID Connect ID tokens carry identity claims (sub, email, name) meant for the client, while OAuth access tokens carry authorization claims (scope, audience) meant for a resource server — the difference is in which claims the issuer chooses to include, not the token format.
You might also need
What is the JWT Decoder?
The JWT Decoder decodes a JSON Web Token's header and payload segments directly in your browser, so you can inspect its claims without pasting it into a third-party website. It never verifies the signature and never claims a token is valid — only that its structure was decoded. A JWT is three Base64URL-encoded segments joined by periods: a header describing the signing algorithm and token type, a payload carrying the claims (who the token represents, when it expires, what it authorizes), and a signature that a server verifies against a secret or public key. Decoding the first two segments is a read operation — it requires no key and proves nothing about authenticity. This tool performs exactly that: it splits the token on its periods, Base64URL-decodes the header and payload, parses them as JSON, and leaves the signature's raw bytes untouched and unverified, because verifying a signature correctly requires the issuer's key material, which no client-side tool should ever be handed. This distinction matters because a JWT's payload is just declared data until a signature check confirms the issuer actually produced it — anyone can construct a JSON object claiming to be an admin token. Decoding is for reading and debugging; verification is a security control that belongs on your server, using the correct key and the algorithm your service expects (never the algorithm named in the token's own header, which an attacker controls).
Use cases
- Inspecting the claims inside an access token or ID token while debugging an OAuth/OIDC flow
- Checking whether a token has expired or is not yet active
- Reviewing custom claims added by an identity provider before wiring up backend verification
- Understanding the structure of a JWT for the first time
- Comparing the claims in two tokens (e.g. before and after a refresh) without a backend tool
- Confirming which algorithm a token's header declares before configuring server-side verification
- Decoding a token pasted from browser dev tools or an API response during support debugging
How to use the JWT Decoder
- 1
Paste the token
Paste a JWT into the input — a leading "Bearer " prefix is stripped automatically.
- 2
Decode
Click Decode JWT (or press Ctrl/Cmd+Enter) to split and decode the header and payload.
- 3
Review the claims
Switch to the Claims tab to see issuer, subject, audience, and expiry/not-before status at a glance.