400 Bad Request

Usage

When a 400 Bad Request error arrives, the client is responsible for examining the message body to learn more about the failure. The server returns sufficient detail for the client to rectify the problem. Common reasons for a 400 Bad Request response include:

When these errors occur, the client might try double-checking the URL, clearing browser Cookies, or compressing an oversized file before retransmitting.

Example

The client requests a resource containing curly bracket characters in the path. These are not valid in a URL, so the server responds with 400 Bad Request.

Request

GET /index{15}.html HTTP/1.1
Host: example.com

Response

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=UTF-8
Content-Length: 131

<html>
  <head>
    <title>Malformed URL</title>
  </head>
  <body>
    <p>Invalid characters in HTTP request</p>
  </body>
</html>

How to fix

A 400 Bad Request means the server rejected the request due to a client-side formatting problem.

Check the URL for encoding errors. Special characters like curly braces, spaces, or non-ASCII characters need percent-encoding. Inspect the full request path and query string. Run the URL through a validator to catch illegal byte sequences.

Validate request headers. A malformed Host header, oversized Cookie header, or missing required header triggers this error. Compare headers against the API specification. Use browser DevTools (Network tab) or curl -v to inspect the raw headers sent with the request.

Inspect the request body for syntax errors. Invalid JSON, broken form encoding, or a mismatch between the Content-Type header and actual body format causes rejection. Validate JSON payloads with a linter before sending.

Clear browser cache and Cookies. Corrupted or expired Cookies produce malformed request headers. Large cookie values exceeding server buffer limits are a frequent trigger. Clear stored data and retry.

Verify Content-Length against the actual body size. A mismatch between the declared and transmitted byte count results in a bad request response.

Check server-side size limits. nginx rejects oversized headers with a 400 when they exceed the buffer configured by large_client_header_buffers (default: 4 buffers of 8 KB). Increase the value in nginx.conf:

large_client_header_buffers 4 16k;

Apache enforces LimitRequestFieldSize (default 8190 bytes) and LimitRequestLine. Raise these in the server config or virtual host:

LimitRequestFieldSize 16384
LimitRequestLine 16384

Enable debug logging to identify the exact cause. nginx logs the rejection reason at the info level. Set error_log to info and review /var/log/nginx/error.log. Apache logs the offending header name in the error log at LogLevel info.

Inspect reverse proxy header forwarding. When nginx or Apache operates as a reverse proxy, an incorrectly set Host, X-Forwarded-For, or X-Real-IP header causes the backend to reject the request. Verify the proxy_set_header directives pass valid values.

Code references

.NET

HttpStatusCode.BadRequest

Rust

http::StatusCode::BAD_REQUEST

Rails

:bad_request

http.StatusBadRequest

Symfony

Response::HTTP_BAD_REQUEST

Python3.5+

http.HTTPStatus.BAD_REQUEST

Java

java.net.HttpURLConnection.HTTP_BAD_REQUEST

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_BAD_REQUEST

Angular

@angular/common/http/HttpStatusCode.BadRequest