JWT Decoder

JWT Decoder & Debugger

Decode, inspect and verify JWT tokens — fast, private, no server upload.

Header

Payload

Signature

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519. JWTs are widely used for authentication and authorization in web applications, APIs, and microservices. When you log in to a website, the server often issues a JWT that your browser sends with every subsequent request to prove your identity.

Unlike traditional session-based authentication that requires server-side storage, JWTs are self-contained — all the information needed to verify the token is encoded within the token itself. This makes them ideal for stateless architectures and distributed systems.

JWT Structure (Header, Payload, Signature)

A JWT consists of three parts separated by dots (.):

  1. Header — Contains the token type (typ: JWT) and the signing algorithm (alg: HS256, RS256, etc.).
  2. Payload — Contains claims (statements about the user and metadata). Claims include registered claims like exp (expiration), iss (issuer), and sub (subject), plus any custom data.
  3. Signature — Created by signing the encoded header and payload with a secret key (HS256) or a private key (RS256/ES256). The signature ensures the token hasn't been tampered with.

Each part is Base64URL-encoded, making the token URL-safe and compact enough to be sent in HTTP headers, cookies, or URL parameters.

Common JWT Claims

The JWT specification defines seven registered claims:

ClaimNameDescription
issIssuerWho issued the token
subSubjectWho the token is about (usually user ID)
audAudienceIntended recipient of the token
expExpirationUnix timestamp when the token expires
nbfNot BeforeToken is not valid before this time
iatIssued AtWhen the token was created
jtiJWT IDUnique identifier for the token

JWT vs Session/Cookie

When building authentication, developers often choose between JWT-based and session-based approaches. Each has distinct trade-offs depending on your architecture:

AspectJWTSession/Cookie
StateStateless — token contains all infoStateful — server stores session data
ScalabilityEasy horizontal scaling (no shared store)Requires shared session store (Redis, DB)
SizeToken can be large (all claims included)Cookie is small (session ID only)
RevocationDifficult (requires blacklist or short expiry)Easy (delete from server)
Security riskToken theft (XSS if stored in localStorage)CSRF attacks (mitigated by SameSite cookies)
Best forAPIs, microservices, mobile apps, SSOTraditional web apps, server-rendered pages

Neither approach is universally better. JWTs excel in distributed, stateless architectures where multiple services need to verify identity without a central session store. Sessions are simpler and more secure for traditional server-rendered applications where immediate revocation matters.

Common JWT Errors and How to Fix Them

When working with JWTs, you may encounter these common error messages. Paste your token into the tool above to inspect the Header and Payload for debugging.

TokenExpiredError: jwt expired

Cause: The exp claim timestamp has passed. The token is no longer valid.

Fix: Request a new token from the authentication server. If you control the server, consider extending the token lifetime or implementing a refresh token flow. Use this tool to check the exact expiration time.

JsonWebTokenError: jwt malformed

Cause: The token string is not a valid JWT format. This usually happens when the token is truncated, corrupted, or not Base64URL-encoded properly.

Fix: Ensure you are copying the complete token string without extra whitespace or line breaks. Check that no URL encoding has been applied to the dots (.) separating the three parts.

JsonWebTokenError: invalid signature

Cause: The signature does not match the Header and Payload. This means the token was either tampered with or signed with a different key than expected.

Fix: Verify that your server is using the correct signing key. If you recently rotated keys, ensure the verification side has the updated public key. Use the Verify Signature feature above to test with your key.

Error: JWT must have 3 parts

Cause: The input does not contain exactly three dot-separated segments (header.payload.signature).

Fix: Make sure you are pasting the complete JWT token. A valid JWT always has exactly two dots. If your token starts with Bearer , remove that prefix before pasting.

JWT Security Best Practices

  • Always set an expiration time (exp) — tokens without expiration never become invalid.
  • Never use alg: "none" — this disables signature verification, allowing anyone to forge tokens.
  • Don't store sensitive data in the payload — JWTs are encoded, not encrypted. Anyone can decode the payload.
  • Use strong signing algorithms — prefer RS256 or ES256 over HS256 for production systems.
  • Keep token lifetimes short — use refresh tokens for long-lived sessions.
  • Validate the iss and aud claims — ensure the token was issued by and intended for your application.

How to Use This Tool

  1. Paste your JWT token into the input field above, or click Paste Sample to try a demo token.
  2. The tool instantly decodes the Header and Payload with syntax highlighting.
  3. Time-based claims (exp, iat, nbf) are automatically converted to human-readable dates in your selected timezone.
  4. Security warnings appear if potential issues are detected (e.g., alg: none, missing expiration, sensitive data in claims).
  5. Click → JSON Formatter to open the decoded payload in our JSON Formatter tool for further inspection.
  6. Optionally, enter your secret key and click Verify Signature to check if the signature is valid.

Privacy & Security

Your JWT token is processed entirely in your browser using JavaScript. Nothing is sent to any server. All decoding, claim analysis, security checks, and signature verification happen locally. You can verify this by opening your browser's developer tools and checking the Network tab — no requests are made with your token data. This tool is safe to use with production tokens and sensitive credentials.