Fix the 400 Bad Request WordPress Error: The Definitive Guide

You are usually doing something specific when this WordPress error appears. You are trying to log in, save a post, upload an image, submit a form, open one URL, or make a plugin action work, and WordPress gives you 400 Bad Request instead.

The 400 Bad Request WordPress error means the server rejected the request before the action could complete. The request may be stale, too large, malformed, blocked by a security rule, or changed by a plugin, browser extension, cache layer, form, editor, or API client.

TLDR: A WordPress 400 Bad Request usually means the server rejected a malformed, stale, too-large, or invalid request. Start with the URL, site cookies, browser, device, network, and upload size; then check plugins, themes, permalinks, .htaccess, logs, host limits, and security signs.

The useful way to fix it is to follow the request path. Start with the parts that are easy to reset. Move toward WordPress files and hosting rules only when the simple checks do not explain the failure.

What It Means

A 400 Bad Request means the server could not understand or accept what it received.

That sounds like a browser problem, but in WordPress the request passes through more than the browser. Cookies, cache, plugins, themes, redirects, rewrite rules, security tools, admin Ajax, the REST API, and host-level firewalls can all touch the request before the page loads or the save action finishes.

The visible problem is one blunt message. The hidden problem is that several layers may have handled the request before it failed.

A 400 is also different from a 404. A 404 means the page or file was not found. A 400 means the request itself looked wrong, unreadable, too large, expired, or unsafe to the server. If you are comparing it with other common WordPress errors, the key difference is that a 400 points to the request itself.

Do not start by editing server files. If a stale cookie is the cause, changing .htaccess only gives you two problems.

Find The Pattern

Before changing anything, write down the exact action that triggers the error. This keeps you from turning a focused request problem into a full-site guessing session.

Capture the URL, error text, action, time, browser, device, network, and recent changes. If you contact your host later, those details are the difference between useful support and a long loop of “please clear your cache.”

Where it appears	Likely cause	Start here
One URL	Bad URL, query string, redirect, permalink, rewrite rule	Clean the URL, reset permalinks
wp-admin or login	Cookies, session, cache, security plugin, large header	Clear site cookies, try private browsing
Editor or Elementor	Plugin conflict, admin Ajax, REST API, expired session	Check the failed request
Upload or form	File size, request size, stale token, WAF block	Try a smaller request
All devices	Server rule, host cache, .htaccess, WAF, host limit	Check logs and host settings
Header-size message	Oversized cookies or request headers	Clear domain cookies

The pattern matters more than the error page. If private browsing works, suspect cookies, cache, extensions, or the logged-in session. If every device fails, stop blaming your laptop and move toward WordPress or hosting checks.

Start Safely

These fixes are boring because they are safe. That is exactly why they come first.

Check The URL

Reload once. If the error happened during a form submit, checkout-style action, or editor save, do not keep refreshing. You may resend the same bad request.

Look for:

If the URL has a long string after ?, remove that part and try the clean URL. If the page loads, the page itself is probably fine. The request details were the problem.

Clear Site Cookies

Clear cookies for the affected domain before clearing your entire browser history.

WordPress login and admin actions depend on cookies. A cookie is a small browser file that stores session details, login state, and sometimes plugin data. If it gets stale or too large, the server may reject the request before WordPress can handle the action.

If the message says Request Header Or Cookie Too Large or Size of a request header field exceeds server limit, start here. A request header is the extra information your browser sends with the request, including cookies and browser details.

Test Another Context

Open the same URL in a private or incognito window. Then try another browser. If needed, try another device or mobile data.

Use this rule:

Ad blockers, privacy tools, password managers, script blockers, and security extensions can also change requests. Disable them for one test, then turn them back on. The goal is diagnosis, not running your browser unprotected.

Flush DNS Last

DNS tells your browser where the site lives. If the site recently moved hosts or changed CDN settings, your device may still be using an old route.

Try another network first. If the site works elsewhere but not on your machine, flush DNS on your device or router. If it fails everywhere, DNS is probably not the main cause.

Check Request Size

Uploads and forms send more data than a normal page view. A large image, long form, file field, stale form token, or security rule can push the request into a 400 error.

Try Less Data

If a 10 MB image fails, try a 200 KB image. If a long form fails, submit the shortest valid version. If the smaller request works, the action itself is probably valid. The problem is size, filtering, or how the form data is being processed. Compress large images or videos, reduce dimensions, and retry. This is safer than raising server limits without proof.

Check Upload Limits

Only check PHP upload size, memory, or max request size after you confirm size is the trigger. Memory helps when WordPress cannot process an upload. It does not fix a bad URL, stale cookie, malformed request, or security block. Raising limits blindly is a classic way to make the site harder to diagnose.

If uploads fail below the file upload size limit your dashboard says should work, ask your host about maximum request body size, upload limits, ModSecurity, and WAF rules.

Review Form Caching

Forms often use hidden fields or tokens to prove the submission is fresh. If a cache plugin serves an old form page, the visitor sees a normal form, but the server sees stale data. Clear the WordPress cache, host cache, and CDN cache if the form page is cached. Then test the same form again. If the host security layer blocked the request, ask for the rule ID and timestamp.

A WAF is a web application firewall. It can be right to block suspicious requests, but it can also block a valid form with a file upload, long field, unusual character, or repeated submit attempt.

Review Recent Changes

If the quick checks fail, look at what changed before the error started. WordPress request problems often follow a plugin update, form edit, page builder change, redirect rule, security setting, code snippet, host move, or CDN change.

Take a backup before disabling plugins or switching themes. Change one thing at a time. If you make five changes and the error disappears, you still do not know what fixed it.

Test Newest Changes

Start with the newest plugin, theme, snippet, or setting change. It is the most likely suspect and the easiest story to prove. Pay special attention to caching, security, form, page builder, redirect, SEO, and custom-code plugins. These tools often touch requests, headers, cookies, redirects, admin actions, or rewrite rules.

Where this goes wrong: people deactivate a random set of plugins, clear every cache, resave permalinks, and then cannot reproduce the fix. Troubleshooting should leave a trail.

Use The Dashboard

If you can access wp-admin, deactivate all plugins and test the broken action. If the error disappears, treat it as a likely plugin conflict and reactivate plugins one by one, testing after each one. This is diagnosis, not the final fix. Once you find the plugin, update it, adjust its settings, replace it, or send the exact failure details to the plugin developer.

Switch to a default WordPress theme for one test if plugins are not the cause. Themes can affect forms, builders, scripts, and custom request handlers.

Use File Manager

If wp-admin is blocked, use your host’s File Manager or SFTP. Rename wp-content/plugins to plugins-disabled. This disables all plugins. If the site or admin works again, rename the folder back to plugins, then test individual plugin folders until you find the cause.

For themes, rename the active theme folder so WordPress can fall back to a default theme if one is installed. Do not delete plugin folders as your first move. Renaming is reversible. Deleting turns a troubleshooting step into a recovery job.

Reset Permalinks

Permalinks control how WordPress maps URLs to content. A broken rewrite rule can make one normal-looking URL fail while the rest of the site works.

Resave Permalinks

Go to Settings > Permalinks and click Save Changes without editing anything. This regenerates WordPress rewrite rules. This is low risk and often helps after migrations, permalink changes, plugin changes, or redirect changes.

Inspect .htaccess

The .htaccess file is a server rules file used on many Apache-based WordPress sites. It can control redirects, security rules, cache behavior, and WordPress rewrite rules. Back it up before touching it. If you are not comfortable editing server files, stop here and ask your host or developer.

Look for old redirect rules, security rules, cache rules, and migration leftovers. If the error affects one URL pattern, a rewrite or redirect rule is a strong suspect. A small rule can have a large blast radius. Treat .htaccess like production wiring, not a note-taking file.

Check Background Requests

Sometimes the page loads, but a background WordPress request fails. This is common during editor saves, Elementor saves, uploads, form submissions, plugin actions, and custom integrations. This is where the request failed with a status code 400, which often appears. The page is still open, but one request behind the page was rejected.

Use Network Tab

Open browser developer tools, go to Network, repeat the action, and look for the request with status 400. You are looking for the failing URL and action. Do not share cookies, authorization headers, nonces, application passwords, or full private request data in public forums.

A nonce is a short WordPress security token that helps confirm an action came from a valid session. If it expires, a save or plugin action can fail even though the page still looks normal.

Check Common Causes

In WordPress, these failures often involve admin-ajax.php, the REST API, a page builder save request, a plugin endpoint, a form endpoint, or custom code.

Common causes include:

JSON is a common data format used by APIs. If the structure is broken, WordPress may reject the request before the action runs.

Share Useful Details

If a developer needs to look at it, send the failed request URL without secrets, status code, visible response message, browser console error, time of failure, recent plugin or code changes, and whether private browsing or another device changes the result.

That is much better than “the editor is broken.” It gives the developer a request to inspect and a timestamp to match against logs.

Clear Cache Layers

Cache can preserve a bad version of a page, form, redirect, or script after the original cause is gone.

Clear cache in a sensible order:

1. Browser cache
2. WordPress cache plugin, using a plugin-specific guide such as BlogVault’s WordPress cache clearing walkthrough when needed
3. Host cache
4. CDN cache

Test the exact broken action after each clear. Do not clear every cache after every tiny change or you will lose the evidence. If you use Airlift for performance, check its caching stack before purging everything.

If a cached form is serving stale tokens, clearing the right cache can fix the submission immediately. If a cached redirect is sending users into a bad URL, the error may look like a WordPress problem even though the cached rule is the real cause.

Check Host Limits

Move to hosting checks when the error happens on all devices, uploads fail below expected limits, the message mentions headers or cookies, or logs suggest a WAF or ModSecurity block.

Ask your host about:

Do not try to raise server header limits yourself unless you manage the server and understand the web server configuration. On managed hosting, this is host work. The decision rule is simple: if the request reaches a host security or size limit before WordPress handles it, WordPress settings may not fix it.

Use Logs

If the error survives the earlier checks, stop guessing and gather evidence.

Check the WordPress logs, PHP error log, web server access log, web server error log, and host security logs. Match entries to the exact time and action you wrote down earlier.

Send support a short note:

We are seeing a 400 Bad Request on [URL/action] at [time and timezone]. It happens on [browsers/devices/networks tested]. It started after [recent change, if known]. We tested [cookies/cache/private browsing/plugins/permalinks/uploads]. Can you check request header limits, request body limits, WAF or ModSecurity logs, server cache, and web server error logs for that timestamp?

This gives support a clear path. A vague “my site has a 400 error” usually produces a vague answer. Use cURL or Postman only if you are comfortable with API testing, and never paste credentials, cookies, nonces, or application passwords into public notes.

Prevent Repeat Errors

Prevention is mostly about keeping requests predictable and changes traceable.

A 400 error is usually not malware. But if it appears with suspicious redirects, injected scripts, unfamiliar admin users, unexpected file changes, or repeated unexplained failures, scan your WordPress site for malware before assuming it is only cache. If malware is confirmed, cleanup matters more than repeating browser fixes.

FAQs

What does it mean?

It means the server rejected the request sent by your browser, plugin, editor, form, or API client. The request may be malformed, stale, too large, blocked, or missing required data.

Can plugins cause it?

Yes. Caching, security, form, page builder, redirect, SEO, and custom-code plugins can change requests, cookies, headers, redirects, REST calls, or admin Ajax actions. Test recent plugin changes first.

Why status code 400?

It usually means a background request failed while the page stayed open. This often happens during editor saves, Elementor saves, uploads, form submissions, REST API calls, or plugin actions.

Can cookies cause it?

Yes. Stale or oversized cookies can make the request header too large or invalid. Clear cookies for the affected domain first.

Can uploads cause it?

Yes. A large file or form payload can exceed upload, request body, memory, or security limits. Test with a smaller file before changing server settings.

Conclusion

The fastest way to fix a WordPress 400 Bad Request error is to follow the request from the browser to the server. Clean the URL, clear site cookies, test private browsing, try another device or network, and check whether upload or form size is the trigger.

If the error persists, move carefully through plugins, themes, permalinks, .htaccess, cache layers, logs, host limits, and security signs. Change one thing at a time and keep notes. That is how you fix the error without making the site harder to diagnose.