JWT Decoder

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe way to represent claims securely between two parties. In practice, a JWT is most often used as an authentication token: after you log in, a server issues a JWT that your browser or app sends back with every subsequent request to prove who you are. Because the token carries its own information, the server can validate a request without looking anything up in a database — making JWTs popular for stateless authentication, single sign-on and API authorization.

A JWT is just a string of three parts separated by dots. It looks random, but it is not encrypted — it is merely encoded. That means anyone who has the token can read its contents, which is exactly what this decoder does. Paste a token and it instantly shows you the header, the payload and the signature, pretty-printed and colour-coded, along with a readable summary of the important claims such as the algorithm, the issued-at time and the expiry. Everything happens in your browser, so the token you paste is never uploaded or logged anywhere.

JWT structure

Every JWT has exactly three sections, joined by dots: header.payload.signature. Each section is Base64url-encoded (a URL-safe variant of Base64), which is why the token can travel safely inside HTTP headers and URLs.

• Header. A small JSON object describing the token. It always contains the signing algorithm in the alg field (for example HS256 or RS256) and the token type in typ (usually JWT). It may also include a key identifier (kid) telling the server which key to use for verification.
• Payload. A JSON object containing the claims — the actual statements about the user or session, such as the subject, expiry and any custom data the application needs. This is the part you most often want to read.
• Signature. A cryptographic signature computed over the header and payload using a secret or private key. Its job is to let the recipient verify that the token has not been tampered with. The signature is not human-readable and cannot be decoded into JSON — it is raw cryptographic output.

To build a JWT, a server takes the header and payload, Base64url-encodes each, joins them with a dot, and signs the result. To read one, you simply reverse the encoding of the first two parts — which is what this tool does. Crucially, decoding and verifying are two completely different operations, a distinction that is at the heart of JWT security.

JWT security: decoding is not verifying

This is the single most important thing to understand about JWTs, and it is why this tool deliberately does not verify signatures. Decoding a JWT just reverses the Base64url encoding so you can read the header and payload — anyone can do it, no key required. Verifying a JWT means recomputing the signature with the correct secret or public key and checking that it matches, which proves the token is authentic and unmodified. The decoded contents of a token are not trustworthy until that verification has been performed on a server that holds the key.

Because of this, you should treat anything you see in a decoded payload as unverified input. Never make a security decision based purely on decoded claims in client-side code, and never paste a production token into a website you do not trust — since the payload is readable, a malicious site could harvest session information. This decoder is safe precisely because it runs entirely in your browser and transmits nothing, but the general lesson stands: a JWT is signed, not encrypted, so it provides integrity, not confidentiality. Anyone who intercepts a token can read every claim inside it.

Several practical security rules follow from this. Servers must always verify the signature before trusting a token, and must reject the none algorithm, which disables signing entirely and has caused real-world vulnerabilities. Tokens should be transmitted only over HTTPS, stored carefully (an HttpOnly cookie resists theft by cross-site scripting far better than local storage), and given a short lifetime via the exp claim so a stolen token quickly becomes useless. Sensitive data such as passwords should never be placed in a payload, because it is effectively public.

Common JWT claims

The JWT specification defines a set of standard registered claims. They are optional but widely used, and this decoder highlights them in its summary:

• iss (Issuer) — who issued the token, typically your authentication server or identity provider.
• sub (Subject) — who the token is about, usually the user's unique ID.
• aud (Audience) — who the token is intended for; a recipient should reject a token whose audience is not itself.
• exp (Expiration Time) — a Unix timestamp after which the token must no longer be accepted. The decoder converts this to a readable date and tells you whether the token has expired.
• nbf (Not Before) — a Unix timestamp before which the token is not yet valid.
• iat (Issued At) — when the token was created, shown here as a human-readable timestamp.
• jti (JWT ID) — a unique identifier for the token, useful for preventing replay.

Beyond these, applications add their own custom claims — a username, roles or permissions, a tenant ID, feature flags, and so on. The decoder pretty-prints the entire payload so you can inspect both standard and custom claims at a glance. Remember that timestamps in a JWT are expressed in seconds since the Unix epoch (1 January 1970, UTC); this tool does the conversion for you, and our Timestamp Converter can help if you need to work with epoch times elsewhere.

JWT signing algorithms: HS256 vs RS256

The alg field in the header tells you how a token was signed, and the two most common choices work very differently. HS256 (HMAC with SHA-256) is symmetric: the same secret key both signs and verifies the token. It is simple and fast, but every service that needs to verify the token must hold the shared secret — which becomes risky to distribute as a system grows. RS256 (RSA with SHA-256) is asymmetric: a private key signs the token and a matching public key verifies it. This is ideal for distributed systems and third-party verification, because the public key can be shared freely while the private signing key stays locked away on the issuer. ES256 (elliptic-curve) offers similar asymmetric benefits with smaller keys. Whatever the algorithm, this decoder reads it straight from the header so you can confirm a token was signed the way you expect — and it flags the dangerous none algorithm, which means the token is unsigned and must never be accepted by a server.

JWT best practices

Working safely with JWTs comes down to a handful of disciplined habits. Always verify on the server before trusting a token, and explicitly check the algorithm against an allow-list so an attacker cannot downgrade it to none or swap RS256 for HS256. Keep tokens short-lived with a tight exp, and use a separate, revocable refresh token for longer sessions, so a leaked access token expires quickly. Transmit only over HTTPS to prevent interception, and prefer storing tokens in an HttpOnly cookie rather than local storage, which is readable by any script and therefore vulnerable to cross-site scripting. Never put secrets in the payload, since it is readable by anyone, and keep payloads small because the token travels on every request. Finally, validate the standard claims — issuer, audience, expiry and not-before — on every request, not just the signature. Following these rules turns JWTs from a common source of vulnerabilities into a robust, scalable foundation for authentication.

The JWT authentication workflow

Understanding where a JWT fits in a typical login flow makes its design clear. First, a user submits their credentials to an authentication endpoint. The server checks them and, if they are valid, creates a JWT — placing the user's ID in sub, setting iat and a short exp, adding any roles the app needs, and signing the whole thing with a secret (for HS256) or a private key (for RS256). The signed token is returned to the client.

From then on, the client includes the token with each request, usually in an Authorization: Bearer <token> header. On every request the server verifies the signature, confirms the token has not expired, checks the audience and issuer, and only then trusts the claims inside. Because all the information needed is in the token itself, the server does not need to store session state — the property that makes JWTs scale well across many servers. When the token expires, the client obtains a new one, often using a longer-lived refresh token, and the cycle repeats.

This decoder is the debugging companion to that workflow. When a request is being rejected, paste the token here to confirm the algorithm, check whether it has expired, and read the claims your server is actually receiving — all without exposing the token to anyone. It is the fastest way to answer "what is actually inside this token?" while keeping security front of mind. Use the Sample button to see a decoded token instantly, then paste your own to inspect exactly which claims your application is sending and receiving.