A 400 Bad Request appears when a server rejects something about the request your browser or app sent. The cause may be a malformed URL, damaged site data, oversized headers, or invalid API input. Most users can diagnose the problem with a few safe checks.
| What you see | Likely cause | Best first action |
|---|---|---|
| One website fails in one browser | Cookies or cached site data | Test a private window, then clear that site’s data |
| A copied link fails | Malformed or badly encoded URL | Reopen the site and navigate manually |
| Uploads fail | Request or file exceeds a limit | Reduce the file or check the site’s limit |
| API call returns 400 | Invalid body, header, parameter, or method | Compare the request with the API documentation |
| Every device fails on the same site | Website, proxy, or server configuration | Check status information or contact the site owner |
Direct answer: An HTTP 400 error means the server rejected a request it considered invalid or malformed. Start by checking the URL, then test a private window and clear that site’s cookies. If the problem continues, inspect extensions, DNS, upload size, request headers, or API data before retrying.
Key Takeaways
- A 400 response points to a problem with the request, not a missing page.
- Retrying the same unchanged request often produces the same result.
- Check site-specific cookies before deleting all browser data.
- API users should inspect the response body, headers, parameters, and JSON.
- Website owners should check logs, proxies, header limits, and request validation.
What Does an HTTP 400 Error Mean?
HTTP status code 400 belongs to the 4xx client-error group. MDN says a server uses it when the request appears invalid or malformed. Repeating the same request without changing it usually fails again.
The error does not always mean the person made a mistake. A browser extension, stale cookie, proxy, or application can alter outgoing data. The useful question is which part of the request changed or violates the server’s rules.
This distinction makes troubleshooting faster. A 404 means the server couldn’t find the requested resource. A 500 response points to an internal server problem instead.
Common Causes of the Error
Several problems can produce the same 400 response. The exact message may reveal more, especially with web servers or APIs. Start with the simplest cause that matches what happened immediately before the error.
- A typo, illegal character, or bad encoding in the URL.
- Corrupted, outdated, or oversized cookies.
- Cached site data that no longer matches the website.
- A browser extension or security tool changing request headers.
- A stale DNS entry or network path problem.
- An upload or request body exceeding a configured limit.
- Invalid JSON, missing parameters, or the wrong API method.
- A proxy, CDN, web server, or application rejecting the request.
What You’ll Need Before You Start
You only need basic access to your browser and device settings. API users should keep the failing request and current documentation nearby. Website owners should also have access to server or application logs.
- The failing page address or API endpoint
- A private or incognito browser window
- Access to site-specific cookies and cached data
- Another browser, device, or network for comparison
- API documentation or server logs when applicable
How to Fix a 400 Bad Request in 8 Steps
- Check the URL before changing settings. Read the address carefully before deleting anything. Look for spaces, extra punctuation, repeated slashes, or copied characters. If the address looks suspicious, open the site’s home page and navigate manually.
Malformed or incorrectly encoded characters can trigger a 400 response. Cloudflare documents improper URL encoding as one cause of this error. This check takes seconds and has no side effects. - Test the page in a private window. Open the same page in a private or incognito window. That test reduces the influence of stored cookies and many extensions. If the page works there, the problem is probably local to your normal browser profile.
Do not treat private mode as the permanent fix. Use the result to narrow the next step. Then clear only the affected site’s stored data before deleting broader browser history. - Clear cookies and cached data for that site. Start with site-specific cookies instead of clearing everything. Large or corrupted cookies can make request headers unacceptable to a server. Reload the page after clearing the affected domain’s stored information.
Firefox lets users clear cookies and site data for a single current website. Other major browsers provide similar site-data controls. Removing one site’s data also keeps you signed in to unrelated websites.
SciTechWiz readers can browse the site’s How To guides for more task-focused troubleshooting. Its Technology section covers broader computer and device topics. Those sections can help when the problem extends beyond one website. - Temporarily disable extensions, VPNs, or filtering tools. Extensions can rewrite headers, block scripts, or change outgoing requests. VPNs and filtering tools can also alter the network path. Re-enable each tool gradually, testing the page again after each one.
A clean browser profile provides an even stronger comparison. If the error disappears there, re-enable extensions gradually. That method helps identify the setting that changes the request.
SciTechWiz’s Software section is another useful reference point for browser and application topics. The site’s PC audio troubleshooting guide follows a similar diagnostic pattern. Change one variable, test the result, and only then continue. - Restart the network and refresh DNS. A stale local DNS entry can sometimes send traffic toward an outdated destination. Restarting the browser, device, and router is a simple first check. If several browsers fail on one device, test another network.
DNS is less likely when only one browser profile fails. It becomes more plausible when several browsers fail on one device. Testing another network can also separate device problems from network problems. - Check upload and request size. Servers often enforce limits for headers, request bodies, and uploaded files. Crossing a configured limit can produce a 400 response or another 4xx error. Reduce the upload size and try again before changing server settings.
Website owners should inspect the exact message and server logs. A message mentioning request headers or cookies points toward header limits. An upload-specific failure points toward body-size or application limits instead. - Validate API requests carefully. Check the endpoint, HTTP method, content type, authentication, query parameters, and request body. Invalid JSON or a missing required field can lead to a client-error response. Correct the reported field before sending another request.
API clients should inspect the full response body before guessing. Postman recommends comparing the failing request with the service’s API documentation. It also recommends checking headers, body parameters, query parameters, and the HTTP method.
Developers can browse SciTechWiz’s Web Development section for related technical reading. Keep a failing request and a working request side by side. Small differences are easier to find when both examples are visible. - Check the website, proxy, or server configuration. Review server logs, application validation, reverse proxies, CDN rules, and allowed host settings. Also inspect header and request-size limits that could reject legitimate traffic. Compare logs from before and after recent configuration changes.
A 400 code is labeled a client error, but server configuration still decides what it accepts. A deployment can suddenly make previously valid requests fail. Do not increase limits without understanding the traffic.
Browser Problem or Website Problem?
A quick comparison can show where to focus. Test the same page across browsers, devices, and networks. Change only one condition between tests so each result remains useful.
| Test result | What it suggests | Next move |
|---|---|---|
| Works in private mode | Cookies, cache, or an extension | Clear site data and test extensions |
| Works in another browser | Browser profile or extension problem | Repair that browser profile |
| Works on another device | Local device or browser issue | Check site data, DNS, and security tools |
| Fails everywhere | Website or shared network issue | Check site status or contact the owner |
| Browser works, API fails | Request-format problem | Inspect API body, headers, and parameters |
Avoid making five changes at once. That approach may fix the page without revealing the cause. A one-change-at-a-time process gives you a more useful diagnosis.
400 vs. 403, 404, and 500 Errors
These codes point to different stages of a failed request. The distinction helps prevent wasted troubleshooting. Use the response code and message together whenever possible.
| Code | General meaning | Typical next check |
|---|---|---|
| 400 | Request appears invalid | URL, cookies, headers, body, or parameters |
| 403 | Server refuses access | Permissions, authentication, or policy |
| 404 | Resource cannot be found | URL path, deleted page, or broken link |
| 500 | Server encountered an internal error | Server logs, application code, or provider status |
MDN’s status-code reference treats 400 as a client-error response. Cloudflare also lists malformed syntax, content, framing, and routing among common causes. Those definitions explain why one visible error can have several technical triggers.
When Should You Contact the Website Owner?
Contact the site owner when the error appears across multiple browsers, devices, or networks. Include the page address, approximate time, and the action that triggered the problem. Do not send passwords, authentication tokens, or private request data.
Website owners should ask for reproducible steps before changing configuration. Logs can show whether the request reached the web server, proxy, or application. A precise reproduction is more useful than a screenshot alone.
Frequently Asked Questions
What does 400 Bad Request mean?
It means the server considered the incoming request invalid or malformed. The problem may involve the URL, cookies, headers, body, or request routing. The message alone does not identify which part failed.
Can clearing cookies fix an HTTP 400 error?
Yes, especially when the problem appears only in one browser profile. Clear the affected site’s data first, then reload the page. This avoids deleting unrelated logins and preferences.
Why does the error happen in only one browser?
One browser may hold different cookies, cached data, extensions, or proxy settings. A private window helps test whether stored browser state is involved. A clean profile provides an even stronger comparison.
Why does my API return status 400?
The request may contain invalid JSON, a wrong method, missing fields, or incorrect headers. Read the API response body before changing code. Then compare the request with the current API documentation.
Should I keep refreshing a page that returns status 400?
Repeated refreshing rarely helps when the request remains unchanged. Change one likely cause before trying again. Start with the URL, private mode, and site-specific browser data.
Your Next Step
Begin with low-risk checks. Verify the URL and test private mode first. Then clear only that site’s stored data.
Continue through extensions, DNS, request size, and API validation only when needed. Keep notes when a problem repeats. That record can save time if the same issue returns.
For more practical technology walkthroughs, use SciTechWiz’s How To and Technology sections. Follow the same one-change-at-a-time method for other device problems. That habit makes troubleshooting faster and easier to repeat.
