Matthew C.
—When working with Axios in a React app, you may encounter the following error:
Axios.js:70 Uncaught (in promise) AxiosError { message: 'Request failed with status code 400', name: 'AxiosError', code: 'ERR_BAD_REQUEST', ... }
The 400 Bad Request response status code indicates that the server can’t process an HTTP request due to an error in the Axios request. There are various potential causes for a bad request error, including:
These errors are not React-specific and can indicate an issue with your server. For example, if a form in your React app has a function to handle form submission of a multipart request like the function below:
async function handleSubmit(event: React.FormEvent<HTMLFormElement>) { event.preventDefault(); try { const form = new FormData(); form.append("my_file", fileInputState.files[0]); const data = axios.post("http://localhost:3000/api/data", form); console.log(data); } catch (error) { console.log(error); } }
The API endpoint, “http://localhost:3000/api/data”, should be set up to handle multipart form data or you’ll get a bad request error.
Multipart requests are often used for file uploads and transferring data of several different types in a single request. If the backend API uses Node.js, you could use middleware to handle multipart/form-data
like Multer.
Here are some methods that you can use to find and fix common causes of a bad request error.
Make sure that your Axios request matches the request expected by the server. Check that you’re using the correct Axios syntax and that your request includes all the required parameters and headers. You should also make sure that the data you are sending in the request is valid and properly formatted.
Use the network tab in your browser dev tools to check the structure of the Axios request sent to the server. You can also use an API development platform such as Insomnia or Postman to test your Axios requests.
You can check the API server logs to get more information about the error if you have access to the server. If it’s a third-party API, check the server’s API documentation to see if there are any requirements or restrictions you need to be aware of.
If you can change the backend code, it may be useful to adjust the API to return a more useful error message or log errors in the server, like indicating if there’s a missing property in a POST request body.
If your Axios request is sending data, make sure that the data format matches the data format expected by the server. For example, if your server expects URL-encoded data you need to send data in the application/x-www-form-urlencoded
format. Axios serializes JavaScript objects to JSON
by default. To send data in the application/x-www-form-urlencoded
format you can set the content-type
header to application/x-www-form-urlencoded
. Axios will automatically serialize the data object to a URL-encoded format. Alternatively, use one of the other approaches outlined in the Axios docs section on encoding URL bodies.
If you are sending a large file in your request, check that the size of the file does not exceed the server file size limit. The specific error would be a 413 Request Entity Too Large error. You can test if this is the cause of the error by uploading a small file. If this is the issue, consider compressing files to reduce their size or using a file format that uses less space, such as uploading a video instead of a GIF, which you can do client side using a library such as ffmeg.wasm.
Try clearing your browser’s cache and cookies. If you use Chrome, you can follow this guide. Browsers store information from websites in their cache and cookies. You may get an HTTP request 400 error if your browser cache or cookies data are corrupted. You may also get the 400 error if the cookies for handling login authentication for a website are expired.
If you have browser extensions, try disabling them. Browser extensions may affect website cookies.
Try clearing your operating system’s domain name system (DNS) cache. Your operating system stores web server information, which includes DNS lookup data, in a local cache. This data decreases page load times by reducing DNS lookup times. A DNS lookup is the process of translating human-readable domain names into computer-readable IP addresses. Outdated or corrupted cached data can cause bad request 400 errors.
To clear your DNS lookup cache, follow this guide.
Tasty treats for web developers brought to you by Sentry. Get tips and tricks from Wes Bos and Scott Tolinski.
SEE EPISODESConsidered “not bad” by 4 million developers and more than 100,000 organizations worldwide, Sentry provides code-level observability to many of the world’s best-known companies like Disney, Peloton, Cloudflare, Eventbrite, Slack, Supercell, and Rockstar Games. Each month we process billions of exceptions from the most popular products on the internet.
Here’s a quick look at how Sentry handles your personal information (PII).
×We collect PII about people browsing our website, users of the Sentry service, prospective customers, and people who otherwise interact with us.
What if my PII is included in data sent to Sentry by a Sentry customer (e.g., someone using Sentry to monitor their app)? In this case you have to contact the Sentry customer (e.g., the maker of the app). We do not control the data that is sent to us through the Sentry service for the purposes of application monitoring.
Am I included?We may disclose your PII to the following type of recipients:
You may have the following rights related to your PII:
If you have any questions or concerns about your privacy at Sentry, please email us at compliance@sentry.io.
If you are a California resident, see our Supplemental notice.