400 Bad Request Error: Causes and Troubleshooting Steps

When a browser or application sends a request to a server, the server responds with an HTTP status code. The 200 OK message means that a request was successfully processed. In contrast, status codes in the 4xx and 5xx range indicate that the server encountered an issue and cannot process the request.

Web administrators and developers use these error codes to determine if the issue is on the client or server side and identify its underlying cause.  

In this article, you will find out what causes the 400 Bad Request error and the fastest ways to fix it.

What Is Error 400: Bad Request?

400 Bad Request is an HTTP status code. Servers return this response if they cannot process a client request because the structure, syntax, or content of the request violates the server's expectations.

When this happens, the browser displays a generic 400 error screen:

Examples of 400 Bad Request messages include:

• 400: That's an error. Your client has issued a malformed or illegal request.
• 400 Bad Request: The request could not be understood by the server due to malformed syntax.
• HTTP 400 Bad Request: The website cannot display the page.
• Bad Request: Your browser sent a request that this server could not understand.

Web admins often create custom error pages to provide more context about the error and guide visitors on what to do next. If a custom error page is configured, the browser displays that page instead of a generic error message.

What Causes Error 400?

Most 400 Bad Request responses occur because there is an issue with the client-side request. Server misconfigurations can also trigger the error, but these instances are less common.

Possible causes of the 400 status code are shown in the sections below.

Client-Side Issues

Some common client-side issues that can lead to a 400 error are:

• Incorrect URL. The URL contains spaces or special characters that are not encoded according to standard URL syntax rules.
• Outdated browser cache or cookies. The session data or credentials stored in the browser cache are no longer valid and do not match the server's expectations.
• Large request body. The data in the request body, such as a high-resolution media file or a form submission with attachments, is too large and exceeds the server's upload size limit.
• Faulty browser extensions. Browser extensions can become outdated or behave unpredictably due to compatibility issues or bugs. As a result, they may modify the request content or headers in ways that break the format expected by the server.
• Stale local DNS cache. IP address mappings stored in the local Domain Name System (DNS) cache are outdated. Requests are being sent to the incorrect server or endpoint, resulting in a 400 error.

Server-Side Issues

Some common server-side issues that can lead to a 400 error are:

• Misconfigured web server. Settings in config files of Apache or NGINX may be too strict, for example, header rules or upload limit sizes, forcing the server to reject incoming requests.
• Application logic error. A backend application written in Node.js, Python, or PHP is not parsing the requests correctly due to coding errors.
• Overly strict firewall rules. Firewall settings, e.g, blocking large IP address ranges or specific headers, can prevent valid requests from being processed.
• Faulty proxy server. A reverse proxy server modifies URLs or headers in transit, and the upstream server cannot interpret the malformed requests.
• SSL misconfiguration. An improperly configured or expired SSL certificate can prevent the server from establishing a secure connection or parsing the request correctly.

API and Backend Issues

API and backend problems can also cause error 400, for example:

• Malformed JSON or XML. The server cannot read the request payload, form submission, or API call because it is not formatted correctly or contains syntax errors.
• Missing required parameters. The expected parameters in the body, query string, or headers are missing.
• Invalid parameter values. The parameter value is outside the acceptable format or range expected by the API endpoint. For example, the data is sent as a string instead of an integer.
• Incorrect headers. Required headers, such as Authorization, Content-Type, or Accept, are missing or using the wrong format. Common examples include using text/plain instead of application/json or omitting the Bearer prefix in token-based authentication.

How to Fix Error 400 as Visitor

If the 400 Bad Request error message appears in your browser, try the solutions in the sections below.

Check the URL

One of the most common reasons for the 400 Bad Request status is a syntax error in the URL string. Typos, unnecessary spaces, or special characters (e.g., #, %, *) can confuse the server and cause it to reject the request.

Try the following steps:

1. Review the URL in the browser's address bar.

2. Ensure the URL is correctly formatted and does not contain invalid characters. For example, the following URL includes an unencoded space, which may cause the 400 error:

https://example.com/servers/dedicated server

3. Check if the space is there by mistake or if it is an encoding issue. A space should be encoded as %20:

https://example.com/servers/dedicated%20server

Refresh the page after correcting the URL to check if the issue is resolved.

Clear Browser Cache and Cookies

Browsers store credentials, certificates, and URLs in their cache and cookies to improve loading speeds and streamline the browsing experience. If the data becomes outdated due to changes on the server, it may reject the request.

To clear the cache in Chrome:

1. Open Chrome and press Ctrl+Shift+Del.

2. Select the Basic tab.

3. Check Cookies and other site data and Cached images and files.

4. Click Delete data and reload the page.

To clear the cache in Firefox:

1. Open the browser and press Ctrl+Shift+Del.

2. Set the time range using the When dropdown.

3. Check the Cookies and site data and Temporary cached files and pages options.

4. Click Clear and reload the page.

To clear the cache in Safari:

1. Access the browser and go to Settings.

2. Open the Privacy tab.

3. Click Manage Website Data.

4. Select a specific site from the list and click Remove, or select Remove All to delete all cookies and cached data.

5. Click Remove Now.

Revisit the website to check if the 400 Bad Request error is resolved.

Disable Browser Extensions

Browser extensions and plugins store data and logic to provide users with added features. If an extension becomes outdated or corrupted, it may trigger the 400 Bad Request error.

To disable an extension in Chrome:

1. Expand the three-dot menu (⋮).

2. Select Extensions and then Manage Extensions.

3. Toggle the switch to disable an extension.

To disable an extension in Firefox:

1. Open the browser and press Ctrl+Shift+A.

2. Find the affected extension in the Enabled list and click the toggle switch to disable it.

To disable an extension in Safari:

1. Go to Safari and select Settings.

2. Access the Extensions tab.

3. Uncheck the box next to the extension you want to disable.

Reload the page to check if the 400 error has been resolved.

Flush DNS Cache

DNS servers store information about domain names and their corresponding IP addresses. If a DNS record is updated on the server while the device still uses an outdated local cache, the mismatch can cause a 400 Bad Request error.

The solution is to flush the local cache, especially if the error occurs on only one device while others can access the site normally.

To flush the DNS cache on Windows:

1. Type cmd in the Windows search bar.

2. Select Run as administrator to open the Command Prompt.

3. Enter the following command in the command prompt:

ipconfig /flushdns 

4. The system confirms that the DNS Resolver Cache has been flushed.

The next time your machine sends a DNS query, the device will retrieve the updated IP address mappings from the DNS server.

Contact Website Owner

If the 400 Bad Request error persists, there may be an issue with the server's configuration. Contact the website's support team and provide the following information:

• The URL you are trying to access.
• The date and time when the error occurred.
• A summary of the troubleshooting steps you have already taken.

Collect and provide as many details as possible to assist the support staff and streamline the troubleshooting process.

How to Fix Error 400 as Webmaster

If a website visitor reports receiving a 400 Bad Request error, complete the steps in the sections below.

Step 1: Replicate the Error

To determine the scope and root cause of the issue:

1. Ask the user to provide the URL where they encountered the 400 Bad Request.

2. Confirm that the URL is valid and belongs to the website.

3. Open an incognito browsing window and try to access the page.

4. If the page loads, instruct the user to follow the steps in the How to Fix Error 400 as Visitor section.

If you can replicate the error, access additional URLs on the website to determine if it affects a specific page, section, or the entire website.

Step 2: Check URL Encoding

Invalid URLs are a common cause of the 400 Bad Request error. This is especially true if users or services generate URLs dynamically, for example, through submission forms.

To identify and fix an incorrect URL:

1. Review the full URL the user is trying to access. Look for unencoded special characters. The following example contains both unencoded special characters and spaces:

https://example.com//search?q=burger & fries

A properly encoded version has the following format:

https://example.com/search?q=burgers%20%26%20fries

2. Paste the URL in an online URL validator (such as URL Encode/Decode) to confirm that it adheres to the URL syntax standard (RFC 3986).

3. Paste the corrected URL into an incognito browsing window. If the page loads, provide the URL to the user.

4. (Optional) If the URL was dynamically built based on user input, review how the input is processed:

• Test the frontend form with special characters to try to reproduce the issue.
• Ensure that user input is sanitized and URL-encoded.
• If necessary, update the backend/frontend logic to escape, reject, or sanitize unsupported characters.

Monitor the affected pages to confirm that the URL generation issues have been resolved.

Step 3: Use DevTools to Review Bad Request

The Browser Developer Tools (DevTools) feature can help you identify malformed requests, oversized cookies, and payload formatting issues.

To inspect the request that triggered the 400 status code:

1. Open the page where the error is reported.

2. Right-click anywhere on the page and select Inspect to open DevTools.

3. Go to the Network tab.

4. Reload the page while DevTools is open.

5. Look for a request that returns a 400 status.

Check for Oversized Cookies

To determine if an oversized cookie is causing the error:

1. Click the 400 response in the Network tab.

2. Open the Cookie header and look for:

• Very long cookie values.
• Missing delimiters or semicolons.
• Duplicate cookie entries.
• Invalid characters.

If there is an unusually large or duplicate cookie, try deleting it manually.

3. Access the Storage tab.

4. Expand the Cookies dropdown menu and select the affected domain.

5. Right-click the cookie and select Delete.

Reload the page to check if the issue was resolved.

Check API Payloads and Form Data

If the error is triggered during a form submission or API call:

1. Select the relevant request in the Network tab.

2. Open the Request Body section.

3. Validate the payload by confirming that:

• All the required fields are present and filled.
• There are no invalid characters.
• The JSON/XML structure is valid, and there are no missing brackets or mismatched tags.

If the request payload is distorted, modify the form logic or API client to match the format and field names defined by the server. Use automation testing tools like Postman or command-line tools like curl to test the request logic manually.

Analyze Request Headers

To find violations in header syntax or formatting:

1. Open the Networks tab and select the request returning the 400 error.

2. In the Headers section:

• Confirm that the Request URL, path, and query string are correctly formatted.
• Look for unexpected headers, duplicate fields, or unusually long values in the Request Headers section.

Identify what part of the request violates the server's expectations and update the client code or request logic accordingly.

Step 4. Check Web Server Configuration

If you have ruled out malformed URLs and client-side issues, the next step is to check web server settings, reverse proxy rules, and CDN configurations. These components sit in front of backend applications and may reject requests if they do not meet size or format expectations.

For example, the 400 Bad Request error can occur if the size of the request header or body exceeds the server's default limits. You can adjust these limits in web server configuration files.

Apache

To check and adjust header and body size limits in Apache:

1. Connect to the server via SSH and open the terminal.

2. Use a text editor, like Nano, to open the Apache configuration file:

sudo nano /etc/apache2/apache2.conf

3. The default maximum header size in most Apache builds is 8 KB. Append the following lines at the end of the file to increase the maximum size to 16 KB:

# Max size of any single request header field
LimitRequestFieldSize 16384
# Max number of header fields allowed
LimitRequestFields 100

4. Press Ctrl+X, then y, followed by Enter to save the changes and exit the file.

5. Test the new configuration syntax:

sudo apache2ctl configtest

6. Reload the Apache service to apply the changes:

sudo systemctl reload apache2 

Resend the request that caused the 400 error to confirm it was resolved.

NGINX

To increase request size limits in NGINX:

1. Use a text editor to open the NGINX configuration file:

sudo nano /etc/nginx/nginx.conf 

2. Add or update the following directives within the http block:

# Limit request body size (e.g., file uploads, POST data)
client_max_body_size 10M;
# Control the size and number of buffers used for large headers
large_client_header_buffers 4 16k;

This allocates four buffers of 16 KB each for reading large headers.

3. Press Ctrl+X, followed by y, and then Enter to save the changes.

4. Test the configuration:

sudo nginx -t

5. Apply the changes:

sudo systemctl reload nginx 

Resend the affected request to check if the 400 error is resolved.

Step 5. Check Application and Server Logs

DevTools may not always expose the underlying cause of a 400 error, especially if the issue originates from the server or backend application logic. In these cases, it is necessary to check the web server and application logs.

On Linux systems, you can monitor logs in real-time using the tail command. For example, to monitor the NGINX error log, enter:

sudo tail -f /var/log/nginx/error.log

The following table lists popular web servers and frameworks and their default error log locations:

When checking logs for 400 errors, complete these steps:

1. Compare 400 error timestamps in web server logs with the application logs. Look for matching IP addresses, request IDs, or user identifiers to trace the failing request.

2. Web server logs do not contain request bodies. To view the payload and validation errors, access the backend application logs and search for messages like:

• ValueError: could not parse JSON
• Unexpected end of input
• Missing required parameter: email
• SyntaxError: Unexpected token } in JSON

Here is an example of a Node.js error log entry:

[2025-06-05T12:08:53.452Z] POST /api/signup 400  
Request Body: { name: "Rich", email: "Evans" }  
Error: Invalid email format

3. Ensure that the request payload follows expected conventions and that:

• All required fields are present.
• The field names match what the backend expects.
• The Content-Type header matches the body format.
• There are no syntax errors in the JSON or XML.

If there are errors, correct the payload or update the backend validation logic.

4. Use your form UI, curl, or Postman after identifying and fixing the issue to resubmit the request:

curl -X POST https://example.com/api/signup \
  -H "Content-Type: application/json" \
  -d '{"name": "Rich", "email": "[email protected]"}'

This confirms that the 400 Bad Request error has been resolved.

How to Prevent Error 400

To reduce the chance of 400 errors on your website or API, you need to:

• Check and sanitize links. All links must be properly formatted. Avoid unsafe characters or encode them using URL encoding functions in your programming language.
• Limit cookie size. Browsers typically support 4 KB per cookie and around 20 cookies per domain. Avoid setting large payloads or session objects in cookies, as exceeding this limit may cause 400 errors.
• Use frontend validation. Implement JavaScript validation to prevent blank fields, invalid characters, and large payloads. Before users submit a form, check that all fields are correctly filled in. For example, make sure an email field value matches the standard email format.
• Set reasonable upload limits. If using NGINX or Apache, set limits for how large request headers and body content can be. This prevents the server from being overwhelmed by large uploads.
• Monitor the website for 400 errors. Utilize logging and error tracking tools, such as the ELK stack, Prometheus, Grafana, or Sentry, to identify issues in real-time.
• Use clear error messages. Send helpful messages that explain what went wrong when rejecting requests. For example, return Missing field: email instead of the generic Bad Request.
• Keep cached data fresh. Configure cache control headers correctly to prevent clients from sending outdated tokens or stale headers.

Conclusion

After reading this guide, you know what causes 400 Bad Request errors, how to troubleshoot them, and how to minimize their impact on your website or API.

HTTP status codes are a regular part of running a website. If working with a CDN like Cloudflare, read our guides for resolving Error 520, Error 521: Web server is down, and 524: A Timeout Occurred errors.