HTTP 400 Bad Request is a client error response indicating the server cannot process a request due to malformed syntax or invalid data. Unlike server-side errors, the problem originates from the client, whether that is a browser, crawler, or API consumer. For SEO and marketing teams, these errors act as roadblocks that prevent content discovery and degrade user experience.
What is Status Code 400?
The HTTP 400 Bad Request status code belongs to the 4xx class of client errors. It signals that the server received a request it cannot process due to [malformed request syntax, invalid message framing, or deceptive request routing] (RFC 9110 HTTP Semantics). When a server returns this code, resubmitting the identical request without modification will produce the same failure.
Some sources describe this error occurring when a client sends an invalid request to the server, typically caused by incorrectly entered URLs or syntax mistakes in the request structure.
Why 400 errors matter
[A high number of 400 errors can negatively affect the usability of websites] (Ryte Wiki). For marketing and SEO operations, the impact extends beyond usability:
- Blocked crawling: Search engine bots cannot access content behind malformed URLs, wasting crawl budget on dead ends instead of indexable pages.
- Lost conversions: Users encountering error pages abandon sessions rather than troubleshooting syntax issues.
- Link equity decay: Internal links pointing to 400 errors pass no authority to destination pages, fragmenting site structure.
- SEO performance degradation: [HTTP 400 errors can negatively impact your site's user experience and SEO performance] (SiteGround), signaling poor site maintenance to search engines and potentially reducing crawl frequency.
Common causes
The error rarely indicates a server malfunction. Instead, investigate these client-side origins:
Malformed URL syntax Web servers reject URLs containing illegal formatting. Specifically, [URLs with consecutive special characters such as %% or unsafe characters like $, [, ], and | trigger the error] (SiteGround). Domain names also cannot include spaces, exceed 63 characters, or start or end with hyphens.
Corrupted cache or cookies Outdated or corrupt browser cache files and expired cookies cause the server to misidentify valid requests. This frequently occurs on Google services when session data expires but remains cached.
DNS cache issues Unsynchronized local DNS caches store outdated domain records, causing your device to request obsolete or invalid addresses that the server cannot resolve.
Oversized uploads Uploading files that exceed server-imposed limits generates immediate 400 responses. For example, attempting to upload a 150MB video to a form with a 100MB limit will fail.
Browser extensions Specific extensions interfering with cookie sessions between browser and server can corrupt request headers and trigger rejection.
How to diagnose and fix 400 errors
Follow this sequence to resolve the issue:
- Inspect the URL: Manually check for syntax errors, illegal characters, and proper encoding. Remove "unwise" characters and ensure the domain contains no spaces or trailing hyphens.
- Clear browser data: Remove cache and cookies through your browser's history settings. For Google-specific errors, clearing cookies is particularly effective.
- Flush DNS: Execute
ipconfig/flushdnson Windows or equivalent commands on Mac and Linux to clear outdated DNS records. - Test extensions: Disable browser extensions one by one to identify conflicts, particularly those modifying headers or privacy settings.
- Compress files: Reduce upload sizes below server limits using local compression tools before retrying.
- Verify network: Switch from Wi-Fi to mobile data to rule out ISP-level DNS issues or unsynchronized network caches.
Common mistakes
Mistake: Treating 400 as a temporary glitch and simply refreshing.
Fix: Refreshing a malformed request repeats the same error. Correct the request syntax or clear corrupt client data first.
Mistake: Allowing 400 responses to be cached.
Fix: Ensure your server configuration prevents caching of 4xx errors. Unlike 404 errors which can be cached based on Cache-Control headers, 400 errors should not be cached because they could lead to valid subsequent requests being incorrectly rejected.
Mistake: Ignoring the error in crawl reports.
Fix: Run weekly bulk checks using site audit tools to catch malformed internal links before they waste crawl budget and frustrate users.
Mistake: Blaming the hosting server immediately.
Fix: [Server misconfigurations causing 400 errors are rare] (SiteGround). Exhaust client-side fixes (cache, cookies, extensions, URL validation) before escalating to server administrators.
Examples
Example scenario: An API accepts JSON payloads to create users. A request containing [unescaped line breaks in the email field] (MDN) returns:
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"error": "Bad request",
"message": "Request body could not be read properly."
}
Example scenario: A marketer shares a campaign URL with double percent signs:
https://example.com/offer%%summer
The server returns 400 because consecutive special characters violate URL syntax standards.
Example scenario: A user attempts to upload a high-resolution video file exceeding the website's 100MB limit. The server rejects the request with a 400 error before processing begins, requiring the user to compress the file to 80MB for successful submission.
400 vs. 404 vs. 500
| Status Code | Meaning | Root Cause | Caching Behavior |
|---|---|---|---|
| 400 | Bad Request | Client syntax error or malformed data | Should not be cached |
| 404 | Not Found | Valid request, but resource missing | Can be cached with Cache-Control headers |
| 500 | Internal Server Error | Server malfunction despite valid request | Not cached |
Use 400 when the request itself is broken. Use 404 when the request is valid but the target does not exist. Use 500 when the server fails despite receiving a properly formed request.
FAQ
Is 400 Bad Request a client or server error?
It is definitively a client error (4xx). The HTTP 400 Bad Request status code indicates that the server received a request but cannot process it due to malformed syntax, invalid message framing, or deceptive request routing. The issue originates from the client side, whether that involves a browser sending corrupt cookies, a crawler requesting malformed URLs, or an API consumer submitting improperly encoded data. Server administrators generally should not need to restart services or repair databases to resolve this error.
Will refreshing my browser fix a 400 error?
No. Since the error stems from a defective request structure or corrupt client-side data, resubmitting the identical request will produce the same failure. The MDN documentation explicitly states that clients receiving a 400 response should expect repeating the request without modification to fail with the same error. You must first correct the underlying issue, such as fixing URL syntax errors, clearing corrupted cache files, or removing expired cookies before attempting access again.
How do 400 errors affect SEO and marketing performance?
They create significant roadblocks for both users and search engines. [A high number of 400 errors can negatively affect the usability of websites] (Ryte Wiki), leading to immediate session abandonment. Furthermore, [HTTP 400 errors can negatively impact your site's user experience and SEO performance] (SiteGround), as they waste crawl budget when search engine bots encounter malformed internal links instead of indexable content. Persistent 400 errors on high-value pages can signal poor site maintenance to search algorithms.
What is the difference between a 400 and a 404 error?
A 400 Bad Request indicates the server cannot understand or process the request due to client-side syntax errors or malformed data. A 404 Not Found indicates the server understood the request perfectly but cannot locate the specific resource requested. Technically, 404 responses can be cached based on HTTP headers like Cache-Control, while 400 errors should not be cached because subsequent valid requests might otherwise be incorrectly rejected. Marketers should fix 400s by correcting URLs, while 404s require content restoration or proper redirect implementation.
Why does clearing browser cache and cookies fix some 400 errors?
Browsers store cached files and cookies to improve loading speed, but these can become corrupted or contain expired session data. When your browser sends these invalid cookies or references corrupt cached files in its request headers, the server rejects the entire request with a 400 status. This frequently occurs on Google services where expired authentication tokens trigger Bad Request responses. Clearing the cache removes these corrupt files, allowing the browser to send a clean, valid request that the server can process.
Can browser extensions cause 400 Bad Request errors?
Yes. Extensions that modify request headers, inject scripts, or manage cookie sessions can inadvertently corrupt the data sent to web servers. For example, privacy-focused extensions might alter user-agent strings or block specific headers in ways that violate the server's expected request format. To diagnose this, disable extensions one by one and attempt to reload the page. If the error disappears after disabling a specific extension, that tool is interfering with your request syntax and should be removed or reconfigured.
