You may already know the 404 error or the 502 Bad Gateway error we covered earlier. The HTTP 400 is a little different from both: it means the server received a request it could not make sense of, and it usually does not go away until someone changes something.
A 400 is classed as a client error, so most of the time the fix is on the visitor’s side: a bad cookie, a mistyped address, a misbehaving browser extension. But WordPress sites can also generate 400s through their own configuration, and if visitors keep reporting one, or the block editor throws it while you are writing, the problem is yours to solve. If the site’s theme or a plugin is sending malformed requests, changing it may be part of the answer.
We start with the common client-side causes and their fixes, then the server-side ones that site owners should check.
Last updated: 2026 for WordPress 6.8 and current browsers.
What is the error 400?
When you request a page, the browser sends the URL, headers, cookies and sometimes a body to the server. HTTP 400 Bad Request is the server’s reply when that request is malformed: invalid syntax in the URL, headers too large, a corrupt cookie, or a body the server cannot parse.
Browsers show it in several forms: “400 Bad Request”, “HTTP Error 400”, “Bad Request – Invalid URL”, “Request Header Or Cookie Too Large” (an NGINX message), or a plain “This page isn’t working” with an HTTP ERROR 400 note in Chrome. Inside the WordPress editor it can appear as “Updating failed. The response is not a valid JSON response” or “Publishing failed” when a save request to the REST API is rejected. To find the cause, work through the possibilities below.
Causes of the HTTP error 400
The following sections cover the most frequent causes and how to fix each. Try them in order; the first two resolve the majority of cases.
1. Browser cache and cookies
Cookies are small pieces of data a site stores in your browser so it can recognise you on the next visit. When a cookie is expired, corrupt, or simply too large, the server may reject the whole request. WordPress logged-in sessions, plugin settings and analytics tools all set cookies, and on a site you administer for years they can accumulate until the request header crosses the server’s size limit, producing the “Request Header Or Cookie Too Large” variant.
Clearing cookies and cache for the affected site is the equivalent of turning it off and on again. In Chrome, click the padlock or site-settings icon in the address bar, choose Cookies and site data, and delete them for this site; Firefox and Safari have the same option in their site information panels. Then reload. A hard refresh with Ctrl+Shift+R (Windows) or Cmd+Shift+R (Mac) is worth trying first.
2. Faulty URLs
A wrong URL normally gives a 404, but a URL with invalid syntax gives a 400 instead, because the server cannot even parse it to look up the page. Typical offenders are unencoded characters that are not allowed in a URL, such as spaces, curly braces, angle brackets or a stray percent sign not followed by two hex digits (for example %2 or %zz). An extra ? or # in the path, or a copied link that picked up surrounding quotation marks, produces the same result.
Check the address bar carefully. Retype the URL by hand, or navigate to the page from the site’s menu and compare. If the bad link is on your own site, in a post, a menu or a redirect rule, fix it at the source. The Redirection plugin’s 404 and error logs, or Search Console’s page indexing report, will show which malformed URLs visitors and crawlers are actually hitting.
3. Broken Add-ons and browser extensions
Extensions can read and modify every page you visit, including the requests your browser sends. An ad blocker that strips a header a site needs, a privacy extension that rewrites cookies, a translation or coupon tool that injects parameters, or simply an extension that has broken after an update can all cause a server to return 400. On the site owner’s side, the same failures inflate your bounce rate for reasons that have nothing to do with your content.
Open the site in a private or incognito window, where extensions are disabled by default. If it loads, an extension is responsible. Disable them all from the browser’s extensions page, confirm the site works, then re-enable them one at a time until the error returns. Remove or update the culprit. If the site fails in a private window too, extensions are not the cause; continue to the next step.
4. DNS Cache issues
Your operating system keeps its own cache of domain-to-IP lookups, separate from the browser cache. If a site changed hosts or IP addresses recently, a stale entry can send your requests to the wrong server, which then rejects them. Flushing the DNS cache is quick and harmless.
- Windows: open Command Prompt and run
ipconfig /flushdns. - macOS: open Terminal and run
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, then enter your password. - Linux (systemd): run
sudo resolvectl flush-caches.
Restart the browser afterwards. If the error remains, the cause is almost certainly on the server, and the site owner needs to look at the next section.
5. Server-side causes on your WordPress site
If multiple visitors report a 400, or you see it in the editor, check these on your own site:
- Upload size. Uploading a file larger than the server allows returns 400 or 413. Check the limit under Media > Add New and raise
upload_max_filesizeandpost_max_sizein your PHP settings if needed. - Header size limits. If logged-in users hit “Request Header Or Cookie Too Large”, ask your host to increase
large_client_header_buffers(NGINX) orLimitRequestFieldSize(Apache), and reduce the number of plugins setting cookies. - REST API blocked. The block editor saves through
/wp-json/. A security plugin, firewall rule or.htaccessedit that blocks it produces save failures. Run Tools > Site Health; it reports if the REST API is unreachable. Whitelist it in your firewall or security plugin. - Plugin or theme conflict. Deactivate plugins and switch to a default theme as described in our WordPress troubleshooting guide, then reintroduce them one by one.
- Server logs. The access log in your hosting panel records every 400 with the exact request, which usually makes the cause obvious.
Which Canyon theme fits
A theme should never be the source of malformed requests: no oversized cookies, no custom AJAX endpoints that bypass the REST API, no scripts that rewrite URLs. Ours follow WordPress coding standards, use core APIs for everything, and are maintained for WordPress 6.8 and PHP 8.2+. If you are replacing a theme that behaves badly, Bloge is a safe choice for a blog and the business theme category covers company sites.
Conclusion
Most 400 errors are solved by clearing cookies, correcting the URL or disabling an extension, and a DNS flush handles a good part of the rest. When the error persists across browsers and devices, it belongs to the server, and the site owner should check upload and header limits, REST API access and recent plugin changes before contacting the host. Give them the exact URL, the time and the access log line.
Further reading from our partners: Turbo casino.