Decode and inspect JWT tokens instantly. View header, payload, and verify signatures. Security validation included. Free, works in your browser.
Use this free online JWT decoder to instantly decode and analyze JSON Web Tokens. Simply paste your JWT token to view the decoded header, payload, and signature. Our JWT decoder tool runs entirely in your browser - your tokens are never sent to any server.
JSON Web Tokens (JWTs) are used for authentication and authorization in modern web applications. This tool decodes JWTs to show their header, payload, and signature.
JSON Web Tokens (JWTs) are a compact, URL-safe way to represent claims between two parties. They're widely used for authentication and authorization in modern web applications.
Every JWT consists of three parts separated by dots (.):
JWT) and the signing algorithm (e.g., HS256, RS256)xxxxx.yyyyy.zzzzz
Header.Payload.Signature
JWTs use standardized claims to convey information:
| Claim | Full Name | Purpose |
|---|---|---|
iss | Issuer | Who created the token |
sub | Subject | Who the token refers to (usually user ID) |
exp | Expiration | When the token expires (Unix timestamp) |
iat | Issued At | When the token was created |
aud | Audience | Intended recipient of the token |
nbf | Not Before | Token is not valid before this time |
exp) to prevent replay attacksJWTs work best for:
Avoid JWTs for:
Yes. This decoder runs entirely in your browser using JavaScript — when you paste a token it is split, Base64URL-decoded, and parsed locally on your device. The token is never sent to our servers, never logged, and never stored, so it is safe to inspect tokens that contain real user data while debugging. You can confirm this yourself by opening your browser's network tab while decoding: no request is made. The usual caveat for any online decoder still applies — only paste production tokens into tools that are explicitly client-side, which this one is.
For reading a token, the decoder displays the algorithm from the header for every standard type — the HMAC family (HS256, HS384, HS512), RSA (RS256, RS384, RS512), ECDSA (ES256, ES384, ES512), RSA-PSS (PS256, PS384, PS512), and the unsecured "none" algorithm. Decoding works regardless of algorithm because reading the header and payload only requires Base64URL decoding, not the signing key. The algorithm field matters most when you move on to verifying or signing a token. For guidance on which algorithms are actually secure to use, see the linked deep-dive.
Often, yes. Base64URL is case-sensitive, so a token that was forced to lowercase somewhere along the way (some logging pipelines, URL handlers, or databases do this) is normally corrupt and will not decode. This tool includes a lowercase-base64 recovery step: when it detects an all-lowercase segment, it searches for the case combination that decodes to valid JSON and flags that the input was recovered. It is a best-effort heuristic — long random claim values may not be fully recoverable — but it rescues many tokens that other decoders reject outright. This recovery feature is unique to this tool and is not something the blog articles cover.
Decoding and verification are two different operations, and the decode view does exactly one of them: it reads the token. It shows you the header, payload, claims, and expiration status, but reading a token does not prove it is authentic or untampered — anyone can decode any JWT without a key. Treat decoded claims as untrusted input. To confirm a token genuinely came from your auth server and was not modified, you must verify the signature with the secret or public key on the server side. The linked guide walks through signature verification end to end.
Yes. Switch from the Decode tab to the Build tab to construct a token from scratch: set the header algorithm, add registered claims (iss, sub, aud, exp, iat) and your own custom claims, choose an expiration preset, and supply a secret (for HMAC) or a PEM private key (for RSA/ECDSA/PSS) to produce a signed token. Signing happens locally in the browser. This is handy for generating test tokens when debugging an auth flow, so you do not have to paste a real production token to reproduce an issue.
The decoder labels each claim it finds, but if you want the background on what registered claims like iss, sub, aud, exp, iat, nbf, and jti represent — and how custom public and private claims differ — read the dedicated claims explainer. Understanding the claim set is what lets you tell, at a glance in the decoded output, whether a token is scoped to the right audience or carries the roles your app expects.
After you paste a token, the decoder reads the exp claim (a Unix timestamp in seconds) and shows the token's expiration status — valid, expired, or not-yet-valid (nbf) — so you do not have to do the timestamp math by hand. Remember that an expired token shown here is informational only: enforcement still happens server-side when the token is verified. For how the exp claim works and how refresh strategies are built around it, see the expiration deep-dive.
A JWT is three Base64URL segments joined by dots: header.payload.signature. This tool decodes and displays the header (algorithm and token type) and the payload (your claims) as readable JSON, and shows the signature as the raw third segment because a signature is a cryptographic hash, not encoded data — it cannot be turned back into readable text, only verified. If a string you paste does not split into exactly three non-empty parts, it is not a well-formed JWT and the decoder will tell you so. If you are deciding whether JWTs are even the right token format for your use case, the linked article covers when to use them.