400 Bad Request: How to Fix It

An HTTP 400 “Bad Request” response means the server received a request but refused to process it because it was invalid or malformed. Visitors, forms and APIs can all receive the same status, but each context requires a different fix.

Before clearing every cache or changing server settings, answer one question: does the error affect one person, one action or the entire website?

What does HTTP 400 mean?

Status 400 belongs to the HTTP 4xx family. It indicates that the request does not match what the server expects: an invalid URL, oversized header, malformed JSON body, missing required field or unsupported data format.

It is useful to separate it from nearby status codes:

• 401: authentication is missing or invalid;
• 403: the request is understood but access is forbidden;
• 404: the requested resource does not exist;
• 413: the upload or request is too large;
• 422: the syntax is understood but the submitted data fails validation.

Find the source of the error

The error appears on one URL

Check the copied address, special characters and query parameters. A truncated URL, unencoded space or duplicated parameter can be enough to trigger a 400 response.

The error affects one person

The browser may be sending an outdated cookie or an oversized header. Test the page in a private window and then in another browser. If it works, remove data for that website only instead of clearing the full browsing history.

The error follows a form submission or upload

Check required fields, date formats, file size and actual file type. The application should identify the rejected field instead of returning a generic Bad Request page.

The error comes from an API

Compare the actual request with the API contract: HTTP method, URL, parameters, Content-Type header, authentication and JSON structure. Incomplete JSON, a trailing comma or a string sent instead of a number are common causes.

Several pages or all users are affected

The cause is likely in the application, reverse proxy, web application firewall or a recent deployment. Record the exact time, URL and action, then inspect the matching logs. Do not disable a security control globally until you understand which rule is involved.

Fix a 400 error as a visitor

1. Open the page from its official address. Avoid an old bookmark or partially copied link.
2. Try a private window. This quickly reveals a cookie or extension issue.
3. Remove data for the affected site. You may need to sign in again afterwards.
4. Reduce the uploaded file. Check both its extension and its real format.
5. Write down the reproducible steps. The URL, time and preceding action help support teams find the request in their logs.

Fix a 400 error as a site or API owner

1. Reproduce it without sensitive data. Use browser network tools or an API client to inspect the method, URL, headers and response.
2. Read application and proxy logs. The server-side message is usually more precise than the public error page.
3. Validate and normalise input. Define accepted formats, size limits and actionable validation messages.
4. Check infrastructure limits. Header, cookie and body sizes, firewall rules and reverse-proxy settings must be consistent.
5. Add a regression test. A valid request should succeed, while invalid input should receive a clear response without leaking internal information.

Can a 400 error affect SEO?

An isolated 400 response on a private API or internal form does not automatically damage the website’s search visibility. However, when a public page intended for indexing keeps returning 400 to Googlebot, Google cannot use its content and may eventually remove the URL from the index.

Google explains that 4xx responses, with exceptions such as 429, do not provide indexable content. Restore a 200 response on the useful canonical URL and correct internal links that generate invalid addresses. See Google’s official HTTP error documentation.

Do not redirect every error to the home page. An unrelated redirect hides the problem and creates a confusing journey.

Prevent Bad Request errors

• validate data in the interface and again on the server;
• encode URLs and query parameters correctly;
• keep cookies and headers reasonably small;
• log a request identifier without storing secrets;
• monitor 400 response volumes per route after deployments;
• cover forms, uploads and API contracts with automated tests.

Key takeaway

Status 400 does not identify a single cause; it only says the request cannot be processed. A private-window test helps visitors, while logs, request details and input validation help site owners find the underlying issue.

If a Bad Request error keeps affecting an important journey, I can help you diagnose and strengthen your web application. You can also continue with the guides to 404, 500 and 502 errors.