JWT Decoder
Decode a JSON Web Token instantly in your browser. View the header, payload, and claims, see expiration and timestamp details, inspect the signature status, and get plain-English security warnings. Free, fast, and private — your token is never uploaded.
How the JWT Decoder works
This tool processes JSON Web Tokens entirely in your browser. It splits the token on
its dots, Base64URL-decodes the header and payload, and parses the resulting JSON with
the native JavaScript JSON.parse() API. Nothing is ever transmitted to a server.
Splitting and decoding
A JWT is three Base64URL strings joined by dots: header.payload.signature.
The decoder separates these segments, converts the URL-safe Base64 alphabet back to
standard Base64, pads it, and decodes each part to UTF-8 text. The header and payload
are then parsed as JSON and pretty-printed.
Claim analysis
The tool recognises the registered claims from RFC 7519
and converts timestamp claims (exp, nbf, iat)
from Unix time into readable UTC and local dates, with a relative status such as
“expired 2 hours ago” or “expires in 5 days”.
Signature is read, not verified
The signature segment is displayed and measured, but it is not verified. Verifying a signature requires the signing secret (for HMAC) or the issuer’s public key (for RSA/ECDSA), which this tool does not have and never asks for. Decoding reveals what a token says; only verification proves it is genuine.
Browser-only processing
No data leaves your browser tab. You can disconnect from the internet after loading the page and the decoder will continue to work. The source code is visible in your browser’s developer tools under the Sources panel.
What is a JWT?
A JWT (JSON Web Token) is a compact, URL-safe token format defined in RFC 7519. It is widely used to carry authentication and authorization data between a server and a client, and between cooperating services in single sign-on and API ecosystems.
The three segments
- Header — declares the signing algorithm (
alg) and token type (typ) - Payload — carries the claims: who the token is about and what it grants
- Signature — a keyed hash that lets a verifier confirm authenticity and integrity
Where JWTs are used
- API authentication — sent in the
Authorization: Bearerheader - Single sign-on — OpenID Connect ID tokens are JWTs
- Session state — stateless sessions encoded as signed tokens
- Service-to-service — short-lived access tokens between microservices
Important: a standard JWT is signed, not encrypted. The header and payload are only Base64URL-encoded, so anyone holding the token can read them. Never place secrets such as passwords inside a JWT payload.
Header, payload, and signature explained
Understanding each segment makes it far easier to debug authentication problems and spot misconfigured or risky tokens.
Header
The header is a small JSON object describing how the token is signed. The key field is
alg — for example HS256 (HMAC), RS256 (RSA), or
ES256 (ECDSA). It usually includes typ (“JWT”) and, for
asymmetric keys, a kid (key ID) identifying which public key to use.
Payload
The payload holds the claims — registered claims like sub, exp,
and iss, plus any custom claims an application adds, such as roles or
permissions. Because it is only encoded, the payload is fully readable by anyone with
the token.
Signature
The signature is computed over the encoded header and payload using the algorithm named in the header and a key. For HMAC algorithms the key is a shared secret; for RSA and ECDSA it is a private key, verified with the matching public key. If even one character of the header or payload changes, the signature no longer matches and verification fails.
This is what makes a JWT trustworthy once verified: a valid signature proves the token was issued by a holder of the key and has not been altered.
Common JWT claims
The JWT standard defines a set of registered claims. They are all optional, but most real tokens use several of them.
iss(Issuer) — who created and signed the tokensub(Subject) — the principal the token is about, usually the useraud(Audience) — the intended recipient(s) of the tokenexp(Expiration) — Unix time after which the token is invalid
nbf(Not Before) — Unix time before which the token is invalidiat(Issued At) — Unix time the token was createdjti(JWT ID) — unique token identifier, useful for replay protection
Timestamps: exp, nbf, and iat are
NumericDate values — seconds since 1970-01-01 UTC. This decoder converts them to readable
UTC and local times so you can immediately see whether a token is current.
JWT security warnings
Decoding a token lets you spot several common security problems at a glance. This tool highlights them, but they should always be enforced in your application code as well.
alg: none— the token is unsigned and can be forged by anyone- Missing
exp— a token with no expiry stays valid forever if leaked - Expired token — the
exptime is in the past and must be rejected - Future
nbf— the token is not valid yet
- Very long lifetime — multi-year tokens are high-value targets if stolen
- Unexpected algorithm — an
algyour stack does not expect - Missing signature — a two-segment token provides no integrity
- Malformed segments — invalid Base64URL or non-JSON header/payload
Do not overclaim: a token that decodes successfully is not necessarily secure. This tool reports “Decoded successfully, but the signature was not verified.” It never tells you a token is trustworthy.
Why signature verification matters
Decoding and verifying are two very different operations. Decoding simply reveals what a token contains — anyone can do it because the header and payload are not encrypted. Verification proves the token is genuine by recomputing the signature with the correct key and checking that it matches.
If your application trusts a token’s claims without verifying the signature, an attacker can
craft a token with any sub, role, or admin value they
like and impersonate any user. A related attack changes the header’s alg to
none or downgrades it to trick a careless verifier. Always verify signatures
with a trusted JWT library, pin the expected algorithm, and check exp,
nbf, iss, and aud before acting on a token.
This tool does not verify signatures. Signature verification requires the signing secret (HMAC) or public key (RSA/ECDSA). Use it to inspect and debug tokens — not to decide whether a token should be trusted.
Privacy: decoded locally in your browser
All decoding happens entirely in your browser. When you paste a token, it is handled exclusively by JavaScript running in your browser tab — it is never transmitted to any server, never logged, and never stored anywhere outside your device.
That said, a JWT is a bearer credential. Anyone who holds a valid, unexpired token may be able to act as the user it represents, so treat real tokens like passwords: avoid sharing them in screenshots, tickets, or chat, and prefer expired or test tokens when you only need to inspect structure.
Technical verification: Open your browser’s developer tools (F12), select the Network tab, and decode a token. You will see zero outgoing requests triggered by the Decode button. The tool works entirely through in-memory JavaScript execution.
Frequently asked questions
What is a JWT?
A JWT (JSON Web Token) is a compact, URL-safe way of representing claims between two parties, defined in RFC 7519. It consists of three Base64URL-encoded segments separated by dots: a header, a payload, and a signature. The header describes the signing algorithm and token type, the payload carries claims such as the subject, issuer, audience, and expiration, and the signature lets the recipient verify that the token was issued by a trusted party and was not tampered with. JWTs are widely used for authentication and authorization in web APIs and single sign-on systems.
What does a JWT decoder do?
A JWT decoder splits a token into its header, payload, and signature segments,
Base64URL-decodes the header and payload, and pretty-prints the resulting JSON so you
can read the claims. It also summarizes registered claims such as expiration
(exp), issuer (iss), and audience (aud), converts
timestamp claims into human-readable dates, and flags common security issues. Decoding
is not the same as verifying — a decoder reveals what a token contains but does not prove
that the token is authentic.
Is my JWT uploaded to any server?
No. All decoding happens entirely in your browser using JavaScript. Your token is never sent to any server, never logged, and never stored anywhere outside your own browser tab. You can verify this by opening your browser’s Network tab in developer tools while decoding a token — you will see no outgoing requests. This makes it safe to inspect tokens locally, though you should still treat any real token as a secret.
Can this tool verify JWT signatures?
No. This tool decodes JWTs but does not verify the signature. Signature verification
requires the signing secret (for HMAC algorithms like HS256) or the
issuer’s public key (for RSA and ECDSA algorithms like RS256 or
ES256), neither of which the tool has. A token that decodes cleanly is not
necessarily authentic or untampered. Always verify signatures in your application using a
trusted JWT library and the correct key before trusting a token’s claims.
What is the JWT header?
The JWT header is the first segment of the token. When Base64URL-decoded it is a small
JSON object that describes how the token is signed. The most important field is
alg, the signing algorithm (for example HS256,
RS256, or none). It often also includes typ
(usually “JWT”) and, for asymmetric keys, a kid (key ID) that tells the
verifier which public key to use. The header is not encrypted — anyone can read it.
What is the JWT payload?
The JWT payload is the second segment of the token and contains the claims — statements
about the subject and metadata about the token. Claims include registered claims defined
by the standard (iss, sub, aud, exp,
nbf, iat, jti) and any custom claims an application
adds, such as roles or user IDs. The payload is only Base64URL-encoded, not encrypted, so
anyone who has the token can read it. Never put secrets such as passwords in a JWT payload.
What does exp mean in a JWT?
The exp (expiration time) claim is a Unix timestamp — the number of seconds
since January 1, 1970 UTC — after which the token must no longer be accepted. When the
current time is past the exp value, the token is expired and a correctly
implemented server will reject it. This decoder converts exp into a readable
UTC and local time and shows whether the token is still valid or has expired, and if so,
how long ago.
What does alg none mean in a JWT?
alg: none means the token is unsigned — it carries no cryptographic
signature. The JWT specification allows it for cases where integrity is provided by other
means, but it is dangerous in authentication contexts: anyone can create or modify a
none token because there is nothing to verify. A well-known class of
vulnerabilities involves attackers changing a token’s algorithm to none to
bypass signature checks. Production systems should always reject none tokens
unless they are explicitly and safely expected.
Is it safe to paste a JWT into this tool?
Decoding happens entirely in your browser and the token is never uploaded, so pasting it here does not transmit it anywhere. That said, a JWT is a bearer credential: anyone who holds a valid, unexpired token may be able to act as the user it represents. Avoid pasting production tokens into any online tool unless you understand the risk, prefer expired or test tokens when possible, and never share a token in screenshots, tickets, or chat. When in doubt, treat a JWT like a password.
Why does my JWT say expired?
A token is marked expired when its exp claim is a time in the past relative
to your computer’s clock. This usually means the token has simply reached the end of its
lifetime and you need to obtain a fresh one by re-authenticating or refreshing.
Occasionally it can be caused by an incorrect system clock on your device. The decoder
shows the exact expiration time in UTC and local time along with how long ago it expired
so you can tell the difference.
Does decoding a JWT change or expose the signature?
No. Decoding only reads and Base64URL-decodes the header and payload; the signature segment is displayed exactly as it appears in the token but is never verified or altered. The signature is a keyed hash of the header and payload, so it cannot be reversed to reveal the signing key. To confirm a token is genuine you must verify the signature in your application using the correct secret or public key.