Can a 400 response be cached?

An HTTP cache can store a 400 response when explicit caching instructions permit it and the other caching requirements are met. The status code alone does not allow caching.

Does a 400 error mean the website's DNS failed?

No. A 400 is an HTTP response from a component that received the request. A DNS lookup failure usually prevents reaching that HTTP response stage.

Can a missing or duplicate Host header cause a 400?

Yes. HTTP/1.1 requires a 400 response if the Host header is absent, appears on multiple field lines, or contains an invalid value. Check how the client or proxy constructs that header.

Will changing the URL fragment after # fix a server's 400 response?

Changing the fragment does not directly fix a 400 because the fragment is not sent in the HTTP request. Page scripts may use it to build a separate request, so its effect depends on the application.

Is 400 the same as 422 Unprocessable Content?

No. A 400 broadly describes a request the server perceives as erroneous. A 422 means the server recognizes the content type and the syntax is valid, but the supplied instructions cannot be processed.

Can an expired authentication token produce a 400?

An application might choose 400 for a token-related request problem, but 401 is the standard status for missing valid authentication credentials. Check the service's response details rather than assuming a token expired.

Can a form show 400 even when its visible fields look valid?

Yes. The submitted request may include hidden fields, an invalid form token, or metadata that is not shown in the form. The service owner can compare the received request with its validation rules.

Does a 400 response body have a standard format?

No. The status code has a defined meaning, but the server can provide an HTML page, JSON error details, or another suitable representation. The client must read the response format the service actually supplies.

How is 414 different from 400?

414 URI Too Long specifically indicates that the request target is longer than the server is willing to interpret. A 400 does not identify that particular length condition by itself.

How is 431 different from 400?

431 Request Header Fields Too Large identifies a refusal caused by header fields that are too large. A general 400 response alone does not make that diagnosis.

How to Fix a 400 Bad Request Error

A 400 Bad Request means the server cannot or will not process a request because it perceives a problem with that request. Start by identifying the exact URL and action that produced the response. A typo, malformed address, unexpected request header, or message the server cannot parse may be involved, but the number 400 alone does not identify which one.

For a simple page visit, checking the address and trying the intended link again may be enough. If the error appears while submitting a form or using an API, record the request method and the response details before changing anything.

Confirm Which Request Returned 400

If your browser or client can show individual network requests, find the one that returned 400. A page can load several resources, and one failing image or API call does not mean the document request returned 400. Note the requested host, path, method, time, and whether the response came directly from the application or from an intermediary. The visible error page may omit these details.

Try to reproduce the failure with the same account and a harmless request. If a link works until you edit its URL, compare the original and edited addresses. If the response appears only for a particular action, identify the input or metadata that changes for that action. For a failure that cannot be reproduced, the owner may need logs to identify the rejected request.

Check the URL and Request Metadata

Look for an accidental space, a missing slash, a broken percent-encoded character, or a copied address that was cut off. A question mark begins the query, and its characters can affect how the server interprets the request. Do not repeatedly alter a signed or transaction URL and assume its parameters are disposable. Return to the original page or ask the owner for a fresh legitimate link if an address was generated for a specific session.

Check API Headers and Body Data

An API client sends more than a URL. Its method, headers, declared content type, body format, and authentication metadata can differ from a browser request. A server may reject malformed request syntax or framing before the application can interpret the intended data. Compare the request with the service's documented requirements, including which fields are required and how the body is encoded.

If the service expects JSON, verify that property names and string values use double quotation marks and that no comma follows the final member or array element. Use a JSON serializer to create the body, and set Content-Type to match the format actually sent. Then check required fields and value types against the API documentation; valid JSON syntax alone does not make the data acceptable.

Check Request Size Limits

Request size also matters, but a large upload is not automatically a 400. The server might use another status, such as 413 Content Too Large, or a gateway may apply a different limit. If the failing request includes a large body or unusually long header, compare its size with the published limits and the server's actual logs.

Compare Client and Server Behavior

When one browser fails but another succeeds, compare the exact URL, account state, extensions, and request details. A stale page or cookie can sometimes lead to a request the server no longer accepts. First use the site's normal navigation to obtain a fresh page and see whether the same safe action works.

If the error details point to a stale cookie or an oversized Cookie header, remove cookies for the affected site through the browser's privacy or site-data settings. Select that site specifically, then reopen it through normal navigation and sign in again if needed. This can reset login state and saved preferences, so record the original error first and retest only a harmless action.

When different clients send requests for the same action and all receive 400, the owner should inspect the server and gateway logs for a common rejection. A deployment or a change to validation or gateway settings may cause requests that previously worked to be rejected. The server may use 400 for an application-specific validation choice, so its documented response body may add useful context.

A browser's GET for a page and an API client's POST with JSON are different requests even if they share a host and path. The account, method, content type, and body must match before a difference in status points to a client-specific cause. A successful request from an administrator account also does not prove that a public request meets the same requirements.

Retest One Safe Change

Change only the suspected cause and retry a harmless request. If an address was mistyped, correct it and use a normal navigation request. If an API body was malformed, make the smallest documented correction in a test environment or with a read-only operation when possible. Record the before and after status and the request property that changed. A successful retry suggests that the change addressed the problem in that request.

For orders, payments, uploads, or other actions that might have succeeded despite an error display, check the application's transaction record before retrying. A browser error can be a poor indicator of whether a backend write happened. If the service supports an idempotency key or another way to prevent duplicates, follow its retry instructions. If the result is still unclear, ask the service owner to check what happened to the original request.

After a server change, confirm that expected invalid requests still receive an appropriate error. Broadly relaxing validation or disabling security rules to make a single 400 disappear can create a different problem.

Report the Failed Request to the Service Owner

If you cannot change the server, send the owner the time with a time zone, the affected route, the method, a redacted request example, and the response status. Explain whether the issue occurs on one device or across clients, and which safe checks have been tried. Remove passwords, session cookies, authorization headers, personal data, and complete payment details before sharing evidence. A request ID from the response can help the owner locate the matching log entry.