Skip to content
Webmaster Tools
Inspect & debugHTTP Status Codes400 Bad Request

400 Bad Request

What HTTP 400 Bad Request means, the usual causes from broken JSON to oversized cookies and plain HTTP on an HTTPS port, and how to fix it on client and server.

All status codes

What 400 means

The server won't process the request because it sees something wrong with it on the client's side: malformed syntax, invalid message framing, or content it can't parse. 400 is defined in RFC 9110 §15.5.1 and is the generic client error, used when no more specific 4xx fits.

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error": "invalid JSON: unexpected token } at position 42"}

A good 400 says what was wrong. A bare "Bad Request" page leaves the client guessing.

Common causes

  • Broken request bodies: invalid JSON (trailing commas, single quotes, unescaped characters), a body that doesn't match its Content-Type, or a missing required field.
  • Cookies or headers too large. nginx answers "400 Bad Request: Request Header Or Cookie Too Large" when a header line doesn't fit large_client_header_buffers. A pile-up of tracking or session cookies on one domain is the classic cause.
  • Plain HTTP sent to an HTTPS port: nginx shows "The plain HTTP request was sent to HTTPS port", as a 400.
  • Malformed URLs: invalid percent-encoding (%zz), raw spaces or control characters, or an over-long query string.
  • A bad or missing Host header, or framing errors such as conflicting Content-Length and Transfer-Encoding, which servers reject to prevent request smuggling.
  • Invalid parameters in an API: wrong type, out-of-range value, unknown enum.

How to fix it as a client

  1. Read the response body; most APIs say which field or byte is the problem.
  2. Validate the JSON you send, and set Content-Type: application/json when sending it.
  3. Clear the site's cookies if a browser gets 400 on every page of one site while other browsers work.
  4. Encode query values with encodeURIComponent (or your library's equivalent) instead of building URLs by hand.
  5. Check the scheme and port: https:// for port 443, and no http:// to a TLS port.

How to fix it on the server

  • Return a specific error message, and the more precise code where one fits: 422 Unprocessable Content for well-formed but invalid data, 415 Unsupported Media Type for the wrong Content-Type, 413 Content Too Large for oversized bodies, 431 for oversized headers.
  • nginx: raise large_client_header_buffers 4 16k; if legitimate cookies are big, but better trim the cookies.
  • Behind a proxy or CDN, check that it isn't rewriting or adding headers the origin rejects; compare a direct request with one through the proxy.
  • Log the reason for every 400 (without the sensitive values) so you can see patterns.

400 and SEO

Google treats all 4xx responses except 429 the same way: the content doesn't exist, so the URL isn't indexed and drops out if it was. A page that answers 400 only to Googlebot, often because of a header or cookie the crawler doesn't send, or a WAF rule, disappears from search. Check important pages with a plain client that sends no cookies. A 400 for robots.txt is treated as if the file doesn't exist, which means no crawl restrictions.

Rebuild the failing request piece by piece, headers and body included, in the HTTP Request Builder.