Skip to content
Rescue 404
Rescue

Server Errors

400 Bad Request

Intermediate Risk: medium

Last reviewed

Hosting access often needed Database access usually not needed

Direct answer

400

A 400 Bad Request means the server understood you reached it but refused the request as malformed or otherwise invalid—oversized/corrupt headers or cookies, bad URL encoding, WAF rejection, or a client sending a body the app cannot parse. Fix or clear the offending request data; this is not a generic “site down” outage.

HTTP 400 is a client-error status: something about this request is unacceptable to the origin or an edge in front of it. On WordPress sites it often appears after cookie bloat, security rules, broken form/API payloads, or reverse-proxy header limits—not because PHP randomly crashed. This guide helps you isolate which request is bad and whether the block is browser-local, WAF, or application-level.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • MDN defines HTTP 400 Bad Request as a client error indicating the server will not process the request due to something perceived as a client mistake, such as malformed syntax or invalid framing. (400 Bad Request)
  • MDN groups 400-class responses as client error responses, distinct from 5xx server error responses. (HTTP response status codes)
  • Cloudflare’s WAF troubleshooting docs cover investigating blocked or challenged requests that security rules reject at the edge. (Cloudflare WAF troubleshooting)

What the error means

Status 400 tells the client the server will not process the request due to what it considers a client-side problem—malformed syntax, invalid framing, deceptive routing, or policy checks that classify the request as invalid. Unlike 404, the path may exist; unlike 403, the issue is often the shape of the request rather than a simple permission deny; unlike 5xx, the origin is intentionally rejecting this attempt. Common WordPress-adjacent triggers include cookies or headers that exceed size limits, corrupt `Cookie` headers after partial clears, ModSecurity/WAF signatures on query strings or POST bodies, JSON/XML APIs receiving invalid payloads, and proxies that rewrite Host or forwarding headers incorrectly. Repeating the identical request usually keeps failing until the request itself changes.

Common symptoms

  • Browser or DevTools Network shows HTTP 400 for a page, admin-ajax, REST, or checkout request
  • Error appears only in one browser profile until cookies are cleared
  • A form, webhook, or mobile API call fails with 400 while simple GETs to the homepage work
  • WAF or host error page mentions “bad request,” “invalid header,” or rule IDs
  • Problem started after adding a security plugin, CDN WAF, or reverse proxy
  • Very long URLs, tracking query strings, or oversized cookies correlate with the failure
  • curl without cookies succeeds but the normal browser session fails (or the reverse for API bodies)

Most likely causes

  1. 01 Cookie header too large or corrupted (browser stored junk for the domain)
  2. 02 Request headers or URL length exceed server/proxy limits
  3. 03 WAF/ModSecurity rule rejecting query string, user-agent, or POST body patterns
  4. 04 Malformed JSON/form body from a plugin, theme script, or third-party integration
  5. 05 Bad URL encoding, illegal characters, or truncated multipart uploads
  6. 06 Reverse proxy sending invalid Host, Content-Length, or transfer-encoding combinations
  7. 07 Client HTTP/2 or HTTP/3 framing issues mis-reported as 400 by an intermediary

What changed before the problem started

  • Security plugin, host WAF, or CDN firewall rules tightened
  • New caching/CDN layer or reverse proxy introduced
  • Marketing pixels/tags ballooned cookie size on the domain
  • Plugin/API integration started sending a new payload shape
  • Server or proxy header-size limits lowered after a host change
  • Browser extension or corporate proxy altering requests

Troubleshooting steps

  1. 01

    Confirm status 400 on the exact failing request

    In DevTools → Network, select the red/failed row and verify status 400 (not 403/404/5xx). Note URL, method (GET/POST), and whether it is document, xhr/fetch, or a static asset. Success signal: you know which single request is rejected.

  2. 02

    Retry in a private window with extensions disabled

    If a clean profile works, clear site cookies for your domain (and parent domain) in the broken browser, then retest. Bloated or corrupt cookies are a top WordPress-adjacent 400 cause. Success signal: the same URL loads without the old cookie jar.

  3. 03

    Compare a minimal curl/request without custom headers

    Request the URL with a simple GET and no cookies. If that works, reintroduce cookies/headers carefully. If it still 400s, the path, query string, or edge rule is at fault—not your local session. Success signal: you know whether the failure is session-local or universal.

  4. 04

    Check host/CDN WAF or ModSecurity event logs

    Look for rule IDs timed with the 400. Temporarily disable the specific rule or set the path to a lower sensitivity in a controlled window—do not turn off the whole firewall permanently. Success signal: the same request returns 200/302 after the rule is adjusted.

  5. 05

    Shorten the URL and strip suspicious query parameters

    Reproduce with a bare path (no UTM/tracking junk). Extremely long query strings and encoded payloads often trip parsers and WAFs. Success signal: the clean URL works; you can then identify the offending parameter.

  6. 06

    For forms/APIs, validate the request body format

    Confirm Content-Type matches the body (JSON vs form-encoded), required fields exist, and nothing truncated the payload. Fix the client/plugin generating the body rather than “repairing” WordPress core. Success signal: a correctly shaped request succeeds in DevTools or API logs.

When to stop troubleshooting

Escalate if WAF rule IDs are opaque and host support must whitelist traffic, checkout/payment requests keep 400ing during business hours, header-limit changes need root access you lack, or you suspect the 400 is hiding an application bug in custom code. Bring the failing URL, status line, response body snippet, and whether a cookie-less request works.

Information to collect before requesting help

  • 01 Exact URL, method, and status 400 confirmation from DevTools
  • 02 Response body or WAF message/rule ID if shown
  • 03 Whether a private window or cookie clear changes the result
  • 04 Recent security plugin, CDN, or proxy changes
  • 05 Whether homepage GET works while a specific POST/XHR fails
  • 06 Hosting/CDN provider and whether ModSecurity/WAF is enabled
  • 07 For APIs: Content-Type and a redacted sample of the request body

How a professional repairs the problem

We isolate the failing request, separate cookie/header limits from WAF and application validation errors, clear or reduce oversized client state, adjust the specific edge/origin rule that rejects legitimate traffic, and verify forms, admin-ajax, and REST callers succeed without disabling security wholesale.

Frequently asked questions

Is 400 the same as the site being down? +
Usually no. Down often means DNS failure, connection timeout, or 5xx. A 400 means something answered and rejected this request as invalid. Other URLs on the same site may still work.
Why does clearing cookies fix my 400? +
The Cookie header can grow past proxy or server limits, or become corrupt. A fresh session sends a smaller, valid header so the request is accepted again.
How is 400 different from 403 Forbidden? +
403 is “I understand the request but will not authorize it.” 400 is “this request is malformed or otherwise unacceptable.” Overlap exists with some WAFs, so always read the response body and rule logs.
Can a plugin cause 400 on admin-ajax or REST? +
Yes. Plugins can reject payloads, and security layers can flag plugin query strings. Confirm in DevTools which endpoint returns 400, then adjust that plugin or the WAF rule hitting it.
Will reinstalling WordPress fix 400? +
Rarely as a first step. Reinstalling ignores cookies, WAF rules, and bad client payloads—the usual causes. Diagnose the failing request before rebuilding the site.
Does 400 mean my server is hacked? +
Not by itself. It more often means bad client data or a strict firewall. Persistent odd 400s paired with strange redirects or unknown admin users deserve a security review, but start with request forensics.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.