You are probably familiar with the HTTP 404 error. It’s when the page or document you’ve requested can’t be found. But what about when you get an HTTP error 400, where you’re given the bad request message? That one is a bit trickier, but not anything to worry about. We want to go through some of the most common reason a 400 error occurs, ways to fix it when it does, and steps you can take to prevent it from happening.
What is the HTTP Error 400?
Of all the HTTP errors that people get, this is one of the more common errors that happens on the user’s end. That’s not to say that server admins don’t have to worry about it. They do. But in many cases, the request is bad from the beginning, and the website can’t make sense of it. So instead of even trying to fulfill it, it just gives you a 400.
Luckily, there are some things you can do to push the request on through to the server processes and get it carried out. Let’s look at some of the causes, then, and how you can fix them.
Browser Cache and Cookie Issues
We’ve said it before, and we will say it again. Clearing your browser cache is the “turn it off, then back on” of HTTP errors. Or really, most internet errors. Unfortunately, doing this will absolutely not fix everything. However, if there’s been a corruption somewhere, an expired cookie, or just something locked up and unable to parse, clearing your browser cache might be able to clear it up.
Many times, a 400 error gets returned on form submission or login. If you are sending secured and encrypted packets, something might go wrong during the process. Sometimes a simple refresh can do it, but other times a full cache urge can clear it up.
Additionally, you can try to bypass the cache when receiving an HTTP error 400 by pressing CTRL/CMD – Shift – R on the error screen. That might help push your request through. If not, then you move on to the other fixes.
Check Your URLs
One of the primary causes of the HTTP error 400 is actually an error in the URL. Not like a typo that generally results in a 404, but an illegal character that isn’t part of the server’s expected syntax.
Let’s go with a simple example. When you’re working with a UTM campaign, you can use %20 and similar codes to insert characters (%20 inserts a space). Like this:
You can put that URL in our browser right now, and it would work. However, if you put a % or %20 in the main part of the URL (the part before the ? that indicates query strings in a URL), the server just has no idea what you’re asking for.
www.elegantthemes.com/%divi will give you this:
Because standard URL structure doesn’t accept that character. Make sure that when you get an HTTP error 400 that you have not malformed the URL in any way. That the URL you’re trying to reach has been correctly typed in. This most likely will happen on URLs that you click, so if you follow a link that gives you a 400 Bad Request screen, check the primary URL for any strange characters that shouldn’t be there.
Check Browser Add-ons and Extensions
Much like WordPress debugging, you want to make sure that third-party software isn’t causing the issue. If you run any browser extensions or add-ons, it’s a very good idea to disable them individually to see if one of them is causing the error to pop up.
You can do it all at once, but then you don’t know who the culprit is. So check them individually. And if you can reload the page and not get a 400 error, then either learn to live without that add-on for a while or check the extensions marketplace to ensure that it’s updated to the most recent version.
File Size is Too Large
This is a huge issue in WordPress. WP users have invariably come across an HTTP error when trying to upload a file. This doesn’t just happen with WordPress, either. But with WP, it’s a very simple fix. However, just to make sure that the 400 that you’re setting is based on file size, upload a smaller file to the server. If it goes through, then there’s a higher chance the file size limit needs to be increased. Also, we’ve had luck with logging out and back in to fix a 400 error based on uploads.
In your wp-config.php file, you should find a line that looks something like this: define(‘WP_MEMORY_LIMIT’, ’64M’);
If you do not find it, you can copy/paste this one in directly above the line that reads /* That’s all, stop editing! Happy blogging. */. Then adjust the 64M to 128M or 256M. Doing so will change the maximum file upload size (in megabyes) for your WordPress site.
You can also change the max file size via your .htaccess file and the functions.php file inside your theme’s directory. If you’d prefer to go that route, we have some great documentation to walk you through the steps.
Flush Your DNS Cache
Flushing your DNS cache can help in much the same way that clearing your browser’s cache and deleting cookies helps. (They’re completely separate, by the way.) The concept is the same, though. Your computer is saving DNS information for sites you’ve been to in order to load them faster upon revisiting them. But…sometimes that old info conflicts with the site’s most recent version. And you get a 400 error.
It’s a pretty easy fix, though. In Windows, you just need to open up the command prompt.
Just enter cmd in the search, and when you get to the prompt, just type in ipconfig /flushdns (with the space). And that might have fixed your HTTP error 400.
If you’re on Mac, it’s very similar. You search for terminal and enter sudo killall -HUP mDNSResponder. If that doesn’t work, try sudo discoveryutil udnsflushcaches.
For other operating systems and a full rundown of DNS caching as a whole, you can check out Kinsta’s excellent guide.
Wrapping Up with the HTTP Error 400
If you still get a 400 after trying all of these solutions, it’s time to contact the web host. If you’re a visitor and know how to contact the website via Twitter or other means, do that. And if you’re the administrator and have to deal with the problem, your best bet is likely the support at whichever host you use. Many HTTP errors like the 400 can be fixed by following simple and easy solutions like the ones we mention here. However, not all can. That’s when the host should be involved. They have a lot more information and access than you do.
How have you dealt with HTTP Error 400 in the past?
Article featured image by Leremy / shutterstock.com