400 Error Code | Fix Bad Requests Fast And Clean

Guide / By

A 400 error code means the server can’t read your request, usually due to a bad URL, cookie, header, or request body.

You click a link and get blocked by a blunt message. Or your app sends an API call and the server pushes back. A 400 response is one of those messages that feels vague until you know where to look.

This guide walks you through the real causes, quick checks, and clean fixes for browsers, WordPress sites, and APIs. You’ll also get a small checklist you can keep near your desk for the next time it shows up. Right now.

What A 400 Error Code Means On The Web

HTTP status codes are short signals a server sends back after it receives a request. The 400 family is “client error,” meaning the server thinks the request is malformed or can’t be processed as sent.

With a 400 response, the server is saying it can’t parse the request. That can be a broken URL, a header that’s too large, a cookie that got corrupted, or a request body that isn’t valid for the endpoint you hit. MDN’s reference describes 400 as “Bad Request,” tied to malformed syntax or invalid request content (MDN 400).

On the standards side, the HTTP Semantics spec defines how these status codes fit in the protocol (RFC 9110).

Where 400 Shows Up Most

  • Browser requests — Loading a page fails after a redirect loop, a bad cookie, or an overgrown request header.
  • Form submissions — A contact form posts data the server rejects or can’t parse.
  • APIs — A client sends invalid JSON, wrong content type, missing required fields, or a query string the server can’t decode.
  • Proxies and CDNs — A middle layer rejects the request before it reaches your app.

Common Triggers Behind Bad Requests

A 400 response isn’t one single bug. It’s a class of problems that share one theme: the request that arrived is not in the shape the server expects. The good news is that you can narrow it down fast with a few patterns.

Broken Or Misread URLs

Typos, stray characters, and bad encoding can all break a request. Copy-pasting a URL from a PDF, chat app, or spreadsheet can introduce invisible characters. Long tracking strings can also get mangled when they’re wrapped across lines.

  • Re-enter the URL — Type it fresh in the browser bar, especially the part after the domain.
  • Strip the query string — Remove everything after “?” and load the clean path first.
  • Check encoding — Watch for spaces, “%” sequences, or unusual characters in the path.

Cookies That Got Corrupted Or Too Large

Cookies ride along with your request headers. If a cookie becomes corrupted, a server can reject it. If cookies grow large, they can also push the request header past limits set by your web server or proxy.

  • Open a private window — Test the same URL without your existing cookies.
  • Clear site cookies — Remove cookies for that one domain instead of wiping everything.
  • Try another browser — This quickly separates a browser state issue from a server-side issue.

Request Bodies That Don’t Match The Endpoint

On APIs and form posts, the request body is a frequent culprit. Invalid JSON, wrong field names, missing required fields, or a mismatched content type can all trigger a 400. MDN shows an invalid JSON body leading to a 400 response (MDN example).

  • Validate JSON — Check that strings are quoted, commas are correct, and the payload is valid JSON.
  • Match Content-Type — Send application/json only when the body is JSON.
  • Confirm required fields — Compare your payload to the endpoint contract.

Headers That Are Too Big

Headers can bloat from cookies, large auth tokens, or forwarded headers. Some servers return 400 when header size crosses a limit. This shows up more on login flows and dashboards that set many cookies.

Symptom Likely Cause First Try
400 only when logged in Cookie or header bloat Clear site cookies
400 on one long URL Bad encoding or huge query Remove query string
400 from API POST Invalid JSON or wrong content type Validate payload format
400 through proxy/CDN only Edge rule rejects request Bypass edge to test origin

Fast Checks When A Page Shows 400

Start with checks that take under two minutes. They solve a surprising chunk of real-world 400s and keep you from chasing server logs when the issue lives in the browser.

Reset Your Browser State

  1. Reload without cache — Use a hard refresh so the browser fetches a fresh copy.
  2. Try a private window — Load the same page with no stored cookies.
  3. Clear only this site — Delete cookies and cached files for the domain that fails.

Test The URL In A Clean Way

  1. Paste the base URL — Load the domain homepage first, then click through.
  2. Remove weird characters — Replace spaces with hyphens and delete trailing punctuation.
  3. Check redirects — If the URL bounces across many redirects, the chain can create a bad request.

When It Only Happens On One Device

If one laptop hits a 400 while your phone loads fine, treat it like a local state issue. Cookies, cached DNS, and security tools differ across devices.

  • Flush DNS cache — Clear your device’s DNS cache so it pulls fresh records from your resolver.
  • Try another profile — A fresh browser profile isolates extensions and stored site data.
  • Check system time — Large clock drift can break signed requests and produce odd client errors.

Rule Out Extensions And VPNs

Extensions that rewrite requests, privacy tools, and VPN browser add-ons can change headers or block scripts that a site expects. That can trigger a 400 or a bad redirect.

  • Disable extensions — Turn them off in batches, then retry.
  • Pause VPN — Test on your normal connection.
  • Switch networks — Try mobile data for one request to rule out a network proxy.

Fixing 400 Bad Request Errors On Your Site

If you own the site, you get more levers. The goal is to replicate the error, isolate where the request breaks, then apply the smallest safe change.

Replicate And Capture The Request

  1. Reproduce in an incognito window — This checks if cookies are part of the trigger.
  2. Record the full URL — Include the query string, not just the path.
  3. Check the response headers — In DevTools, scan for proxy headers that hint at an edge rejection.

Check Server And Proxy Limits

Web servers and reverse proxies set limits for header size, request line length, and body size. When a request crosses those limits, you can get a 400 before your app code runs.

  • Review header size limits — Check your web server and proxy config for header buffers and max sizes.
  • Scan cookies — Audit how many cookies your site sets and how large they get after login.
  • Review upload limits — File uploads or large form posts can trigger request size limits.

Fix WordPress Patterns That Trigger 400

On WordPress, 400 responses often come from security plugins, cached rules, or a plugin that rewrites URLs. Another common trigger is a huge cookie set from plugins that store large data in cookies.

  • Disable one plugin at a time — Start with security, cache, and redirect plugins.
  • Clear caching layers — Purge plugin cache, server cache, and CDN cache if you use one.
  • Check permalinks — Re-save Permalinks to rebuild rewrite rules.
  • Inspect WAF logs — Check blocked requests and the rule ID tied to the block.

Send A Helpful Error Response

If you run an API, return a small JSON error body that points to what failed. A clear error message reduces repeated retries that just slam the same bad request. MDN shows a 400 response with a message field to guide a retry (MDN response body).

Developer Checklist For Forms, APIs, And Proxies

This section is for cases where a 400 keeps firing in code, not in a browser. The best fix is to make the request deterministic and visible.

When A Form Post Fails

  1. Log raw input safely — Store field names and lengths, not personal data.
  2. Validate on the server — Reject early when required fields are missing.
  3. Normalize encoding — Handle UTF-8 input and reject invalid byte sequences.

When An API Call Fails

  1. Print the exact request — Method, URL, headers, and body should be visible in logs.
  2. Check Content-Type — Align body format and header value every time.
  3. Confirm auth format — A malformed token header can trigger a 400 at a gateway.
  4. Validate JSON schema — Catch missing fields and wrong types before sending.

When A Proxy Or CDN Is In The Middle

Edge layers can reject requests based on size, header patterns, or rules meant to block abuse. When the error appears only behind a proxy, test the origin directly. Then compare headers and request size between the two paths.

  • Bypass the edge — Hit the origin IP or a direct hostname that skips the proxy.
  • Compare request headers — Check for added headers or stripped headers.
  • Check request size — Measure total header bytes and payload size.

Preventing Repeat 400s In Real Work

Once the page loads again, it’s tempting to move on. A small set of habits can cut repeat 400s and make the next incident easier to fix.

Keep URLs Clean

  • Limit tracking parameters — Keep query strings short and stable.
  • Encode safely — Use proper URL encoding for spaces and non-ASCII text.
  • Avoid fragile redirects — Keep redirect chains short and consistent.

Keep Cookies Under Control

  • Set fewer cookies — Remove cookies that aren’t needed after login.
  • Store data server-side — Keep large state out of cookies and into sessions.
  • Audit cookie size — Watch totals after new plugins or tags are added.

Make Crawlers And Users See The Right Status

If your site uses 4xx responses for blocked traffic, be deliberate. Google’s crawling docs explain how status codes affect crawling and indexing (Google status code behavior).

A 400 can be correct for malformed requests, yet it’s not a substitute for a missing page response. Return 404 for missing content, 401/403 for auth, and 429 when rate limits are hit. Using the right code keeps logs clearer and avoids crawl confusion.

Keep A Short Incident Note

  1. Write the trigger — URL, payload, headers, and the point where it failed.
  2. Write the fix — Config change, plugin change, code change, or client-side cleanup.
  3. Write the guardrail — A test, alert, or limit that stops a repeat.

If you can reproduce it, you can fix it, add a test so it stays fixed.

The next time a 400 error code appears, you’ll know where to start: strip the URL, clear the site cookies, confirm request format, then check proxy limits and logs. Those steps solve the majority of cases without guesswork.