---
title: 400 Bad Request
description: What HTTP 400 means, the usual causes from malformed JSON to oversized headers, and how to find which part of the request the server rejected.
canonical: https://watchfor.io/docs/reference/http-status-codes/400
---

# 400 Bad Request

What HTTP 400 means, the usual causes from malformed JSON to oversized headers, and how to find which part of the request the server rejected.

**400 Bad Request** means the server refused to process the request because the
request itself is defective — malformed syntax, invalid framing, or contents
that fail basic validation. It's the generic client-error code: when nothing
more specific (401, 404, 413, 422…) fits, servers reach for 400.

## Common causes

- **Malformed JSON body** — trailing commas, single quotes, unescaped
  characters. Validate payloads with a [JSON formatter](/json-formatter) before
  blaming the API.
- **Wrong `Content-Type`** — sending JSON with
  `application/x-www-form-urlencoded` (or vice versa); many frameworks then
  parse an empty body and reject the request.
- **Oversized or corrupt headers** — a cookie that grew past the server's
  header-size limit is a classic: the site 400s for one user and works for
  everyone else. Clearing cookies "fixes" it.
- **Invalid URL encoding** — unencoded spaces, `%` sequences, or characters in
  the path/query that the server refuses.
- **Missing required parameters** — APIs that validate early often 400 before
  more specific errors get a chance.
- **Protocol violations** — bad chunked encoding, conflicting
  `Content-Length`, HTTP/2 framing errors introduced by a buggy proxy.

## Who's at fault?

By definition the client — but "the client" includes every layer that touched
the request: your SDK, a proxy rewriting headers, a load balancer with a lower
header limit than the app. A request that works with `curl` but 400s from your
application means the difference is in what your application adds.

## Debugging

1. Reproduce the exact request with the free [API tester](/api-tester) — same
   method, headers and body — and vary one thing at a time.
2. Read the response body; well-behaved APIs say *what* was bad.
3. Compare limits along the path: application server, reverse proxy and CDN
   each have their own max header/body sizes, and the smallest one wins.

For APIs you own, an [API monitor](/docs/monitors/api) sends a known-good
request on schedule — if that starts returning 400, a deploy changed
validation, not the clients.

---

Canonical page: https://watchfor.io/docs/reference/http-status-codes/400 · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt