Bad Request: What It Means and How to Fix It

A “Bad Request” error means a server rejected a request because it could not understand or accept what the browser or app sent; it is commonly shown as HTTP 400. To fix it, check the address and request details, clear site-specific cookies or cached data, and try again; if the problem continues, the website or an intermediary may need to be corrected.

What a Bad Request error means

HTTP status codes are messages exchanged between a client—such as a browser—and a server. A 400 response indicates that the server considers the request invalid or malformed. The exact wording varies: a page may say “400 Bad Request,” “HTTP Error 400,” or simply “Bad Request.” The response can come from the website’s server, a reverse proxy, a content delivery network, or another service handling the request.

Unlike a “Not Found” response, which generally means the requested resource could not be located, a 400 points to a problem with the request itself. It does not necessarily mean the person using the browser did something wrong. A site defect, a browser extension, a network proxy, or incorrectly formatted data from an app can also cause it.

Why it happens

A request contains information such as the URL, headers, cookies, and—when submitting a form or sending data—sometimes a body. Servers may reject it if some part is invalid, too large, incomplete, or inconsistent with what the service expects. Common causes include:

• Incorrect or malformed URL: A typo, invalid character, extra punctuation, or damaged link can produce a request the server cannot parse.
• Oversized cookies: Old or excessive site data can make the browser send a cookie header that exceeds a server or proxy limit.
• Invalid form or API data: A missing field, unexpected format, or malformed JSON can be rejected by the receiving service.
• Request size limits: A large upload or unusually long URL may exceed limits set by the server or an intermediary.
• Browser or network interference: Extensions, VPNs, proxies, or security software can change or block parts of a request.
• Server-side configuration: A website may incorrectly reject valid requests, especially after a change to its software or infrastructure.

The displayed error alone rarely identifies which cause applies. A useful first distinction is whether it affects one page or many, one browser or several, and one person or many users.

How to fix it in a browser

Try these steps in order, stopping when the page works. Menu names vary slightly across browsers, but site-data and privacy settings are usually available in the browser’s settings.

1. Check the address. Re-enter the URL carefully or open the site’s home page and navigate to the page again. Remove accidental spaces, punctuation, or duplicated parts. If the link came from a message, ask for a fresh link if it may have been cut off.
2. Reload and retry once. A temporary network or server issue may clear on a new request. Avoid repeatedly submitting a form or payment-related action; first check whether the site recorded the original submission.
3. Open the page in a private window. If it works there, stored site data or an extension is a likely factor. Private browsing is a diagnostic test, not a guarantee of privacy from websites or network operators.
4. Clear data for that site. Remove its cookies and cached files, then visit it again and sign in if needed. Clearing all browser data is usually unnecessary and may sign you out of many sites.
5. Temporarily disable extensions. Test with content blockers, script tools, or privacy extensions turned off for the site. Re-enable them afterward and change only the setting that appears to cause the issue.
6. Try another browser or network. This helps isolate a browser-specific problem from a site or network issue. If a VPN or proxy is active, test without it only if doing so is appropriate for your network and privacy needs.
7. Update or restart the browser. A restart can clear a stuck session; installing available browser updates can resolve compatibility issues.

What to do if you run the website or app

If you are a site owner or developer, begin by reproducing the request and examining server or proxy logs. Check the request method, URL encoding, headers, cookie size, content type, body format, and payload size. Compare a failing request with one that succeeds, while avoiding the collection or exposure of passwords, session tokens, or other sensitive information.

For an API, confirm that the client sends the format the endpoint expects—for example, valid JSON when the endpoint requires JSON—and that required fields are present. Return a useful error message that identifies the invalid input without revealing internal details. Check any limits imposed by the application server and by gateways or proxies in front of it; changing only one layer may not solve a limit enforced elsewhere.

Do not treat every 400 as a reason to retry automatically. A malformed request usually needs its contents corrected. If a request is valid but rejected, inspect configuration and recent changes rather than asking users to repeatedly clear their browsers.

How to tell whether the problem is yours or the site’s

Testing another browser, device, or network can narrow down the source, but it cannot prove it. If the error appears only on one browser, cookies or extensions are plausible. If it occurs across browsers and devices for the same page, the URL, account-specific data, or website may be involved. If many users report the same failure, a server or intermediary issue becomes more likely.

When contacting the site’s support team, provide the page address, approximate time, the exact error wording, and the steps that triggered it. Mention what you already tried. Do not send passwords, authentication codes, or full screenshots containing private account details.

Frequently Asked Questions

Is a 400 Bad Request error my fault?
Not necessarily. A malformed URL or browser data can cause it, but an app, website, proxy, or server configuration can also generate the problem.

Does clearing cookies fix a 400 error?
It can, especially when a site’s stored cookies are too large or outdated. Clear data for the affected site first; this may sign you out there.

Is HTTP 400 the same as 404?
No. A 400 means the server rejected the request as invalid. A 404 generally means the server could not find the requested resource.

Why does a 400 error happen only on one website?
That site may have problematic cookies, a malformed link, an account-specific request, or a server-side issue. Testing the site in a private window or another browser can help isolate it.

Can I fix a 400 error on a phone?
Yes. Check the link, reopen the page, and clear that site’s browser data if needed. You can also test another browser or switch between Wi-Fi and mobile data to identify a local cause.

What should I do if nothing fixes it?
Contact the website or app’s support team with the page address, error text, time, and troubleshooting steps. If you maintain the service, inspect request and intermediary logs.

Related

• Raspberry Pi Pico vs Zero: Key Differences
• Raspberry Pi Projects to Set Up Before Vacation
• ESP32 E-Paper Flight Tracker: Build One for Your Desk