Decode and inspect the header and payload of any JSON Web Token, with readable claim dates, right in your browser.
JWT Decoder splits a JSON Web Token into its three parts (the header, the payload and the signature) and decodes the header and payload from Base64URL into readable JSON. It also interprets the standard time claims, so issued-at, not-before and expiry timestamps appear as human-readable dates alongside their original Unix values, and the tool tells you at a glance whether the token has expired. This is ideal for debugging authentication flows, inspecting what claims a token carries, verifying algorithm choices and checking expiry without writing any code. All decoding happens locally in your browser, so tokens containing sensitive data are never sent to any server. Note that decoding does not verify the signature — that requires the server's secret or public key.
JSON Web Tokens are the most widely used format for stateless authentication on the web. When you log in to an application, the server typically issues a JWT that your browser sends with every subsequent request inside an Authorization: Bearer header. The header identifies the signing algorithm (HS256, RS256, ES256 and others). The payload carries claims: who the user is, what roles or permissions they hold, when the token was issued, and when it expires. The signature proves the token was created by a server holding the correct key. Developers reach for a JWT decoder constantly: to confirm what a new auth service puts in the payload, to check expiry after a user reports being unexpectedly logged out, to verify the algorithm during a security review, and to extract user identifiers when writing integration tests.
Reviewed by the ToolBrainy Team · Runs entirely in your browser · Last updated July 2026
A JWT is three Base64URL-encoded strings separated by dots, typically beginning with "eyJ". Copy the full token from your browser's DevTools Network tab (look for the Authorization header value after "Bearer"), from Postman, a log file or a test fixture. Paste the whole string (all three parts) into the input box. The tool decodes it immediately, no button needed.
The header panel shows the signing algorithm (alg) and token type. The payload panel shows every claim: the subject (sub), the issuer (iss) and any custom fields your application adds such as role, email or permissions. Expiry (exp), issued-at (iat) and not-before (nbf) appear as both their original Unix timestamp and a readable local date. A green chip means the token is still valid; a red chip means it has expired.
Click Copy payload to grab the decoded payload JSON for pasting into a ticket or test file, or use Download .json to save it. The raw signature string is shown at the bottom for reference but not verified. Verifying a JWT requires the server's secret key or public certificate, which should never be pasted into a browser tool.
Tokens are decoded locally and never uploaded.
Expiry and issued-at claims shown as real dates.
Instantly see whether a token has expired.
No signup, no limits and no watermarks, ever.
A user reports being logged out after 30 minutes even though sessions should last 24 hours. Paste their token, check the exp chip, and immediately see the actual expiry time, confirming whether the problem is the token lifetime configuration or something else in the auth flow.
Your app returns 403 Forbidden for a request that should succeed. Paste the user's token and look at the payload: if the role field shows "viewer" instead of "admin", or the permissions array is missing the expected scope, you have found the problem without querying a database.
Confirm that tokens use a strong algorithm before shipping an API. A token with "alg": "none" in the header is a critical security finding. Decoding a sample token here takes five seconds and is a good habit before any auth-related code review.
When writing tests that call your API with real tokens from a staging environment, decode a sample token to find the exact sub or user_id values to assert against, without hardcoding guesses or querying the auth service separately.
Social login providers like Google and Microsoft issue ID tokens as JWTs. Decode one to see the email, name, email_verified flag and issuer before writing the code that consumes those fields, useful when integrating an identity provider for the first time.
Paste the example token from the tool, examine all three parts, then note that the signature would no longer be valid if you changed any character in the payload, a clear, hands-on illustration of how the format provides integrity without encryption.
Paste the widely-used sample token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c and the decoder splits it at the two dots. The header reads {"alg":"HS256","typ":"JWT"} and the payload reads {"sub":"1234567890","name":"John Doe","iat":1516239022}, so you can see the signing algorithm and every claim at a glance.
Real access tokens usually carry an expiry claim such as "exp":1735689600. That number is a Unix timestamp, and the decoder turns it into a readable date — in this case the very start of 2025 — so you can tell instantly whether the token is still valid or has already expired.
Every JWT is three Base64URL parts joined by dots: header.payload.signature. Change a single character in the payload and the signature no longer matches, which is exactly what stops someone quietly rewriting "role":"user" into "role":"admin". This tool shows the first two parts; checking the third one needs the signing key.
Yes. This tool is completely free with no signup, no limits and no watermarks.
Yes. The token is decoded entirely in your browser using JavaScript. Nothing is sent to or stored on any server, so it is safe to inspect tokens that contain sensitive claims.
No. This tool decodes and displays the header and payload, but it does not verify the signature. Verifying a JWT requires the secret key for HMAC algorithms or the public key for RSA and ECDSA, which you should never paste into an online tool.
They are standard JWT time claims: iat is issued-at (when the token was created), nbf is not-before (the earliest time the token is valid), and exp is the expiry time. All three are stored as Unix timestamps (seconds since 1 January 1970). This tool converts them into readable local dates and flags green (valid) or red (expired) next to the exp claim.
Decoding reads the header and payload, which are simply Base64URL-encoded JSON. No key is needed and anyone with the token can do it. Verifying the signature confirms that the token was genuinely issued by a server holding the correct secret or private key and that the payload has not been tampered with since it was issued. Decoding is enough to inspect claims and check expiry. Verifying is what your server must do before trusting those claims in production.
Yes. The header and payload are encoded, not encrypted. Any tool can read them without a key. Only signature verification requires the secret or public key, and this tool does not perform that step. This is also why you should not put sensitive data into a JWT payload that you would not want exposed. Every party holding the token can decode and read it.
A JWT is three Base64URL segments separated by dots. The first is the header, which names the signing algorithm. The second is the payload, which holds the claims — who the token is for, when it expires, what it grants. The third is the signature, created from the first two parts and a secret key, which proves the token has not been tampered with.
It names the algorithm used to sign the token. HS256 means a shared secret (HMAC) signed it, so the same secret verifies it. RS256 means a private key signed it and a matching public key verifies it. If you ever see "alg":"none", treat it as a red flag — it means the token is unsigned and should not be trusted.
You can change the payload text, but the token will stop working. The signature is calculated from the original header and payload, so any edit breaks it, and a server that verifies signatures will reject the tampered token. Reissuing a valid token requires the signing key, which is exactly the point of the design.
A traditional session cookie is just an ID; the server looks up the real data in its own store. A JWT carries the claims inside the token itself, so the server can trust it after checking the signature without a database lookup. That makes JWTs handy for stateless APIs, but it also means you cannot instantly revoke one the way you can delete a server-side session.
Length grows with the number of claims. A token that carries a user ID, roles, permissions and issuer details will be far longer than one with just a subject and expiry. Because the whole token travels on every request, it is worth keeping the payload lean and leaving large or rarely-needed data out.
Yes to both. Decoding runs in your browser, so it keeps working if your connection drops and behaves the same on a phone as on a desktop — useful for checking a token's claims or expiry while debugging away from your machine.