A 400 Bad Request is an HTTP status code indicating that the server could not process the request because the client sent something the server couldn’t understand. Unlike server-side errors (which start with 5xx), a 400 error signals a problem with the request itself — malformed syntax, an invalid URL, oversized data, or corrupted cookies — before the server even attempts to fulfill it.

The 400 code is a “client error,” meaning the issue originates with the request being made rather than with the server receiving it. In plain terms: the server received a message it couldn’t read. This could be caused by a browser sending stale or corrupted data, a URL containing invalid characters, a file upload that exceeds server limits, or a third-party integration sending a malformed request.

For business website owners, a 400 error typically appears as an unexpected page visitors encounter when trying to access a URL or submit a form. While usually a quick fix, a recurring 400 error on a high-traffic page or checkout flow can meaningfully impact conversions and user experience.

How 400 Bad Request Errors Work

The HTTP request cycle works like this: a browser sends a request to a server, the server processes it, and returns a response. When everything works correctly, that response is a 200 (OK). When the server receives a request it literally cannot parse or process — due to malformed data — it returns a 400 status code and stops.

Common technical causes include:

  • Invalid or malformed URL — A URL containing illegal characters (like unencoded special characters or extra % symbols) triggers a 400 because the server can’t resolve where the request is pointing.
  • Corrupted or outdated browser cookies — Cookies that have expired, been corrupted, or no longer match the server’s expectations can cause the server to reject the request entirely.
  • Oversized request or file upload — Web servers have maximum request size limits. Uploading a file that exceeds the server’s configured limit returns a 400 error. In WordPress, this is a common trigger.
  • DNS cache mismatch — If the DNS data cached on a visitor’s device is out of sync with the current server records, the request may be malformed before it even reaches its destination.
  • Bad cookies from a plugin or integration — In WordPress, plugins that manage authentication, session data, or API requests can generate malformed request headers that trigger 400 errors.

[Image: Browser showing a 400 Bad Request error page with an HTTP status code indicator]

Purpose & Benefits of Understanding 400 Errors

1. Faster Diagnosis and Resolution

Recognizing what a 400 error means allows you to diagnose it efficiently. Because it’s a client-side error, many 400 issues can be resolved by the visitor — clearing cache and cookies, correcting the URL, or trying a different browser. Understanding this distinction saves time that would otherwise be spent investigating the server when the issue is elsewhere.

2. Better Hosted Infrastructure Decisions

Recurring 400 errors — especially those tied to file uploads — often reveal server configuration limits that need adjustment. WordPress sites with strict upload size restrictions may generate 400 errors for users trying to submit contact forms with attachments or upload images in certain contexts. Our WordPress hosting configurations are tuned to avoid these friction points by default.

3. Proactive Quality Assurance

Monitoring for 400 errors in server logs or tools like Google Search Console can surface problems before they become widespread. A form that’s intermittently returning 400 errors may be silently dropping submissions. A URL pattern generating 400s may indicate a broken integration or a malformed link in an email campaign. Regular error log review is part of responsible WordPress maintenance.

Examples

1. Visitor Encounters a 400 Error on a Contact Form

A visitor fills out a contact form on a business website and clicks submit. Instead of a confirmation page, they see a 400 Bad Request error. In this case, the form is submitting to a URL that the server can’t resolve — often because a plugin update changed the endpoint URL or introduced a conflicting rule. Clearing cache or disabling the conflicting plugin typically resolves it.

2. Image Upload Fails in WordPress Admin

A team member tries to upload a large product photo through the WordPress media library and receives a 400 error. The server’s upload size limit is set lower than the file size. The fix requires adjusting the upload_max_filesize and post_max_size PHP settings on the server — a hosting-level configuration change that’s quick for a managed host to implement.

3. Bad Cookie Causes Checkout Failure

A returning customer on a WooCommerce store tries to complete a purchase and sees a 400 error during checkout. Their browser has a stored cookie from a previous session that no longer matches the server’s session data. Clearing browser cookies resolves the issue immediately. From the site owner’s perspective, this error appears sporadically and is difficult to reproduce — it affects visitors with stale session data from the specific store.

Common Mistakes to Avoid

  • Assuming the problem is on the server — Because 400 is a 4xx error (client errors), the issue is almost always with the request rather than the server infrastructure. Start troubleshooting on the client side — clearing cache, checking URLs — before escalating to your host.
  • Ignoring recurring 400 errors in logs — A single 400 error is usually a visitor or URL issue. A pattern of 400 errors on specific URLs or forms in your server logs is a signal that something in your site configuration needs attention.
  • Not testing forms after plugin updates — Security plugins, caching plugins, and form plugins can all interfere with request handling. After any significant plugin update, test your most important forms and user flows to catch newly introduced 400 errors before your visitors do.

Best Practices

1. Monitor Error Logs Regularly

Set up Google Search Console and review your hosting error logs on a regular basis. Errors that appear sporadically often go unreported by visitors — they simply abandon the action they were trying to complete. Proactive log monitoring catches 400 errors before they accumulate into a conversion problem. This is standard practice in any WordPress maintenance workflow.

2. Configure Appropriate Upload and Request Limits

Work with your hosting provider to set upload size and PHP memory limits appropriate for your site’s use case. Most WordPress sites benefit from upload_max_filesize of at least 32MB–64MB and corresponding post_max_size adjustments. Sites with WooCommerce product uploads or media-heavy workflows may need higher limits. Correct configuration prevents a common class of 400 errors proactively.

3. Test Key User Flows After Every Major Update

Any time you update WordPress core, a theme, or a significant plugin — especially security plugins, form plugins, or caching tools — run through your key user flows: contact forms, checkout, login, file uploads. A five-minute post-update check can catch 400 errors before real visitors encounter them.

Frequently Asked Questions

What’s the quickest way to fix a 400 Bad Request error I’m seeing?

Start with the simplest fixes first: clear your browser cache and cookies, then try the URL again. If that doesn’t work, check that the URL is correctly formatted with no unusual characters. If you’re still seeing it, try a different browser or device. If others report the same error, the issue is on the site side rather than your browser.

Is a 400 error bad for SEO?

A single, isolated 400 error has minimal SEO impact. A recurring 400 error on an important page — if search engine bots encounter it consistently — can result in that page not being indexed or indexed incorrectly. Monitor Search Console’s Coverage report for patterns of 400 errors affecting crawlable URLs.

What’s the difference between a 400 and a 404 error?

A 404 error means the server understood the request but couldn’t find the requested resource — the page doesn’t exist. A 400 error means the server couldn’t understand the request itself — the request is malformed. Different causes, different fixes.

What’s the difference between a 400 and a 500 error?

A 400 error is a client-side problem — something wrong with the request. A 500 Internal Server Error (and other 5xx codes) indicates a server-side problem — the server received the request but failed to process it due to an internal issue. If you’re seeing 400 errors, look at the browser, URL, or site configuration. If you’re seeing 500 errors, look at the server or application code.

Can a WordPress plugin cause 400 Bad Request errors?

Yes, and it’s one of the more common causes on WordPress sites. Security plugins in particular — those that manage authentication, rate limiting, or firewall rules — can incorrectly flag legitimate requests as malformed. Form plugins and REST API-dependent tools can also generate 400 errors if their request formatting conflicts with server-level rules. Deactivating plugins one at a time is the standard diagnostic approach.

Related Glossary Terms

How CyberOptik Can Help

Site performance and reliability directly impact your user experience and search rankings. Our managed WordPress hosting is configured to minimize these error types, and our team monitors and resolves server configuration issues so they don’t become visitor problems. If you’re seeing recurring 400 errors or other HTTP errors on your site, we can diagnose and resolve them quickly. Learn about our hosting solutions or our WordPress maintenance services.