JsonWebTokenError: jwt malformed (Node / jsonwebtoken)

Fix it yourself

Follow the repair

1. Split the Authorization header — never pass it whole. If your token travels in the standard header, the extraction should look like this:

   const authHeader = req.headers.authorization; // "Bearer eyJhbGciOi..."
   const token = authHeader && authHeader.split(" ")[1];

   Search your code for jwt.verify( and look at what is being passed. If it is req.headers.authorization directly, you have found the bug: verify was chewing on the word "Bearer" as if it were part of the token.
2. Check the token exists before you verify it. A missing token is not an error in your code; it is a request with no login attached, and it deserves a clean answer, not a stack trace:

   if (!token) {
     return res.status(401).json({ error: "No token provided" });
   }
   try {
     const decoded = jwt.verify(token, process.env.JWT_SECRET);
     req.user = decoded;
     next();
   } catch (err) {
     return res.status(401).json({ error: "Invalid or expired token" });
   }

   This shape — extract, check presence, then verify inside a try/catch — turns every flavour of bad token into a tidy 401 and keeps the malformed error out of your logs for good.
3. Look at the token's shape safely, without logging the token. When it still fails, inspect the shape only — never print a real token to logs or a chat, because a logged token is a working login for whoever reads it. Length, dot count, and the first few characters are enough:

   console.log("token type:", typeof token, "length:", token?.length,
               "dots:", token?.split(".").length - 1, "starts:", token?.slice(0, 6));

   A genuine JWT has exactly two dots and usually starts with eyJ. Zero dots means it is not a JWT at all (an API key? a session ID? the word Bearer?). One long string starting with "Bearer" means step 1 was skipped somewhere. An undefined type means the value never arrived — go to the next step.
4. If the token is undefined, trace where it was supposed to come from. Follow the chain backwards: does the frontend actually send the header (check the request in the browser's network tab)? Is the backend reading the exact header or cookie name the frontend sets — names must match character for character? If the token comes from an environment variable, confirm that variable exists in the environment that is failing — set locally but missing on the hosting provider is the usual story, and the app must be restarted or redeployed after adding it.
5. Check the secret is loaded, too — for the error that comes next. While you are in the environment settings, confirm JWT_SECRET (or whichever variable your verify call reads) is actually set in this environment. An undefined secret does not cause "malformed" — it causes confusing failures right after you fix the token shape. One check now saves a second debugging round: verify the variable exists, do not print its value, and make sure the signing code and verifying code read the same variable name.
6. Test all three arrivals. With the fixes in: a request with no token should get a clean 401 "no token" response; a request with a garbage token should get a clean 401 invalid-token response; and a request with a real token from an actual login should sail through. If the third one now fails with "invalid signature" or "jwt expired", celebrate quietly — you have graduated to a different, more specific error, and your token extraction is working.