JWT Decoder

A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties. You will encounter JWTs as authentication tokens in almost every modern web API: the access token in OAuth flows, the session cookie in single-page apps, the bearer token in mobile API calls. When something goes wrong (the user gets a 401, the API rejects a request, a token seems to expire too soon), decoding the JWT and reading what is inside is usually the fastest way to figure out what is happening.

ToolHub JWT Decoder runs entirely in your browser. The token you paste is decoded locally using the standard Base64URL and JSON parsers. Nothing is uploaded, logged, or tracked. This matters because production JWTs often contain user IDs, email addresses, role information, and other sensitive data you do not want a third party touching.

1. 1

   Paste your token

   Drop the JWT into the input box. The decoder accepts the raw token, with or without the Bearer prefix you see in HTTP Authorization headers.
2. 2

   Read the colorized output

   The token splits into three color-coded parts: red header, purple payload, blue signature. The same colors appear in the decoded sections below so you can see at a glance which part of the original string maps to what.
3. 3

   Inspect claims

   Standard JWT claims (iss, sub, aud, exp, iat, nbf, jti) are highlighted with descriptions. Custom claims show in a collapsed section. Expiration and issued-at times are translated into human-friendly relative time.
4. 4

   Copy what you need

   Each section has a copy button. Grab just the raw header, the decoded payload as JSON, or the signature.

A JWT is three Base64URL-encoded strings joined by dots: header.payload.signature. Each part has a specific job.

The header

A small JSON object that says how the token is signed and what type it is. Example:

{"alg": "HS256", "typ": "JWT"}

The most common alg values you will see are HS256 (HMAC with SHA-256, symmetric key), RS256 (RSA signature, asymmetric), and ES256 (ECDSA signature, asymmetric). Watch out for alg: none, which is a deliberate vulnerability some libraries used to allow. Modern libraries reject it.

The payload

A JSON object containing the actual claims. Some claims are standard (defined in RFC 7519); others are custom and specific to your application. Standard claims include:

• iss: issuer (who created the token, like https://your-auth-service.com)
• sub: subject (who the token is about, usually a user ID)
• aud: audience (who the token is meant for, like your API)
• exp: expiration time (Unix seconds; tokens past this are rejected)
• nbf: not before (token cannot be used before this time)
• iat: issued at (when the token was created)
• jti: JWT ID (unique identifier for this specific token)

The signature

A cryptographic signature computed over the header and payload using the algorithm specified in the header. The signature lets the recipient verify the token has not been tampered with. Verifying requires the secret (for HMAC) or public key (for RSA / ECDSA), which is why a decoder cannot tell you if a signature is valid without that key.

JWT is not encrypted

The payload of a JWT is Base64URL encoded, not encrypted. Anyone with the token can read the claims. Never put passwords, secrets, or sensitive personal information in a JWT payload. If you need encryption, use JWE (JSON Web Encryption), which is a different standard.

Long expiration times are dangerous

Once a JWT is issued, it is valid until exp even if the user changes their password or you delete their account. There is no way to revoke an individual JWT without server-side state (which defeats the point). Keep access tokens short (5 to 15 minutes) and use refresh tokens for longer sessions.

The alg none attack

Some older JWT libraries accepted tokens with alg: none, meaning no signature was required. Attackers exploited this to forge tokens. Modern libraries reject this by default but always specify the expected algorithm explicitly when verifying.

Algorithm confusion

Another classic attack: a server expects RS256 (asymmetric) but is tricked into verifying an HS256 token using the public key as a symmetric secret. Always pin the algorithm you expect when verifying.

Storing JWTs in localStorage

A common debate: JWTs in localStorage are vulnerable to XSS attacks (any script on your page can read them). JWTs in HttpOnly cookies are vulnerable to CSRF unless you add SameSite or CSRF tokens. There is no perfect answer; pick the trade-off you can defend.

Can you verify the signature in this tool?

No. Verifying a signature requires the secret key (for HMAC) or public key (for asymmetric algorithms). We do not have your keys and cannot guess them. Use this tool to inspect the contents; verify signatures with a backend library that has access to your keys.

Is my token uploaded anywhere?

No. Decoding happens entirely in your browser using standard atob and JSON.parse APIs. Open browser developer tools and watch the Network tab while decoding: zero requests carry your token.

What if my token has more than three parts?

A standard JWT has exactly three parts. If yours has more, you may have a JWE (JSON Web Encryption) with five parts, or extra dots inside one of the parts that should be escaped. The decoder reports an error in that case.

Why are some characters different from regular Base64?

JWTs use Base64URL, a URL-safe variant. Plus is replaced by hyphen, slash by underscore, and equals padding is dropped. Our decoder converts back to standard Base64 before decoding.

Can I edit and re-encode a token?

Not in this tool. Re-encoding would require signing the new token with your secret, which we do not have. Use a backend library (jsonwebtoken in Node, PyJWT in Python) for re-issuing.

• No file or network upload
• Works offline once the page is loaded
• Open source decoding logic, inspectable in the browser
• Compatible with private and incognito browsing