Free JWT Token Decoder – Decode JSON Web Tokens Online

What a JWT Is and How the Decoder Works

A JSON Web Token arrives as one long string with two dots in it, and to the naked eye it is meaningless. Those dots are the giveaway: a JWT is three Base64URL-encoded segments joined together, a header, a payload and a signature. This decoder splits the string at the dots, decodes the first two segments and prints them as formatted JSON so you can read exactly what the token asserts. Backend developers chasing a 401, mobile developers checking whether a refresh flow fired, and anyone learning how OAuth or OpenID Connect actually works all end up doing this several times a week. Doing it in a browser tab beats writing a throwaway script every time. The mechanics are simple once you know the layout. Split on the dot character to get three parts. Base64URL differs from standard Base64 in two ways: it uses hyphen and underscore in place of plus and slash so the value is safe inside a URL, and it usually drops the trailing equals padding. The decoder restores the padding, converts the characters back, decodes the bytes as UTF-8, then parses the result as JSON. The header names the signing algorithm in its alg field and the token type in typ. The payload holds the claims: sub for the subject or user id, iss for the issuer, aud for the intended audience, iat for issued-at, exp for expiry and nbf for not-before, all timestamps expressed as seconds since the Unix epoch, plus whatever custom claims your application adds. The third segment is left as-is because it is a raw signature, not encoded text. Here is a real token payload. The header segment eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 decodes to an object saying alg is HS256 and typ is JWT. A payload might decode to sub user_4821, iss helperzy-auth, iat 1772000000, exp 1772003600 and role editor. Convert those two numbers and the picture is clear: issued at 06:13:20 UTC on 25 February 2026, expiring at 07:13:20 the same morning, so the token had a sixty-minute life. If the current time is past that exp value, every properly configured server will reject the request no matter how well-formed the token looks, which explains a great many mysterious 401 responses. Concrete debugging jobs. An API integration starts failing at exactly the same point in each test run, and decoding the token shows a fifteen-minute exp that the test suite outruns. A single sign-on setup rejects logins because the decoded iss reads staging-auth while the production API expects a different issuer. A permissions bug turns out to be a role claim spelled editor where the middleware checks for Editor with a capital letter. A developer building a new endpoint decodes a sample token from the identity provider to learn which custom claims are available before writing the authorisation check. In all four the answer was visible in two seconds once the payload was readable. The one thing to understand properly: decoding is not verifying. This tool shows what a token says, it does not prove the token is genuine. Verification needs the signing key, the shared secret for HMAC algorithms such as HS256 or the public key for RS256 and ES256, and it must happen on your server. Which leads to the pitfall people get badly wrong: a standard JWT is signed, not encrypted. The payload is readable by anyone holding the token, so never put a password, an API secret or confidential personal data in it. Use JWE if you genuinely need the contents hidden. Decoding runs entirely in your browser and nothing is uploaded, but a live token is still a credential, so avoid pasting production ones you would not want on screen.

Learn More — JWT Decoder Guide

🔥 Trending Tools