HTTP 400 Bad Request: What It Means and How to Fix It

What this error means & how to recognize it

• A browser, API client, uptime monitor, webhook sender, or other HTTP client reports 400 Bad Request.
• The response may appear only for a particular URL, HTTP method, query string, request body, header set, or client.
• DNS can resolve and TLS can complete because the endpoint returned an HTTP response.
• The response body may show a generic error page or a more specific validation message, depending on the component that generated it.
• Response headers may reveal cache status, proxy or CDN information, authentication context, redirects, or request identifiers.
• A previously working request may start returning 400 after a deployment or a routing, validation, proxy, or security-rule change.

Root causes, ordered by likelihood

1. Malformed or invalid request details: The URL, query string, headers, cookies, method, or request body may not satisfy the endpoint's expected format.
2. Application validation or routing rules: The application may reject missing, incorrectly typed, unsupported, or inconsistent parameters, or the request may target a route that does not accept that method.
3. Web-server, reverse-proxy, CDN, or WAF handling: An intermediary may reject the request before it reaches the application because of parsing, routing, filtering, or policy rules.
4. Request-size or format limits: A body, header set, URL, cookie collection, or uploaded value may exceed an environment-specific limit or use an unsupported format.
5. Authentication or session-related request state: An application may use 400 for an invalid token, malformed session data, or a request that cannot be associated with the expected state. Other systems use 401 or 403 for related access problems, so confirm the behavior in the relevant logs.
6. Recent configuration or deployment changes: Updated routes, validation logic, authentication, caching, proxy, CDN, or security settings can change how an otherwise familiar request is processed.

How to fix it

If you are a visitor or API consumer

1. Retry the exact URL once and check for typing errors, unintended spaces, truncated query parameters, or an outdated bookmark.
2. If the request requires an account, sign in through the site's normal process and retry. Do not paste passwords, cookies, or tokens into support requests.
3. If you are using an API client, compare the HTTP method, required parameters, headers, content type, and request body with the endpoint's documented requirements.
4. If a browser request fails, try the same action without repeatedly refreshing. Repeated requests can add load or interact with rate limits.
5. Record the URL or endpoint, method, approximate time, response status, and any request ID shown in the response. Share only sanitized details with the site owner.
6. If the error affects only one action, report that action and its expected behavior. If many unrelated pages fail, report the broader scope rather than assuming every failure has the same cause.

If you own or develop the site

1. Capture a minimal reproduction. Record the HTTP method, full URL with sensitive values removed, status, response headers, relevant request headers, content type, and a safely minimized request body. Confirm that the 400 is the final response rather than an intermediate response followed by a redirect.
2. Compare a working and failing request. Check the route, method, query parameters, body format, content type, cookies, authentication state, client, and payload size. Change one relevant variable at a time.
3. Identify the responding layer. Use response headers, body wording, request IDs, and timestamps to determine whether the application, web server, reverse proxy, CDN, or WAF produced the response. Header names and values are environment-specific, so treat them as clues rather than proof.
4. Inspect the matching logs. Search the identified layer and adjacent components using the same timestamp, route, method, and request identifier. Look for parser errors, validation failures, rejected methods, limit violations, routing mismatches, or security-rule matches.
5. Review recent changes. Compare deployments and configuration changes affecting routing, request parsing, authentication, caching, proxy forwarding, CDN behavior, and WAF rules. Check whether the failing request is expected to be accepted by the route.
6. Apply the narrowest safe correction. Correct the request contract or the specific route or rule that is rejecting valid traffic. Avoid broad security, permission, size-limit, or proxy changes without authorization and testing.
7. Retest and check neighboring behavior. Repeat the original request, then test the intended method, a representative invalid request, and related routes. Confirm that the correction does not turn malformed requests into unintended successes or break redirects, authentication, caching, or security controls.
8. Preserve useful evidence. Keep sanitized request details, timestamps, relevant headers, and logs according to your normal retention and privacy practices.

Prevention & how to verify the fix

• Define and document accepted methods, parameters, content types, authentication requirements, and request-size limits for important routes.
• Validate requests consistently and return a useful, non-sensitive error message where appropriate.
• Keep routing, proxy, CDN, authentication, caching, and WAF configuration under change control.
• Test representative valid and invalid requests after application or infrastructure releases.
• Monitor 400 rates by route, method, client, and deployment so a localized regression is distinguishable from a broad change.
• Retain request identifiers and relevant logs long enough to correlate a response with the component that produced it.
• Redact passwords, cookies, authorization values, personal data, and API secrets from logs and support evidence.

Frequently asked questions