400 HTTP Error | Fix Bad Request Fast

A “400 Bad Request” shows up when a site is reachable but refuses what your browser or app sent. Most of the time it’s a small mismatch: a copied link with odd characters, a cookie that went bad, or a request header that grew too large.

Start with quick fixes that don’t change your system, then move into deeper checks. If you manage a site or build an app, you’ll also get a tight way to pinpoint the field, header, or edge rule that triggers the block.

What A 400 Bad Request Means In Plain Terms

HTTP status code 400 is the server saying it can’t accept this request. The server is responding, so this isn’t a “site is down” problem. It’s usually validation, parsing, or size limits.

Some pages show extra text with the 400. Treat it like a clue. “Invalid URL,” “Invalid Host Header,” or “Request Header Or Cookie Too Large” points you toward the right layer.

How To Tell If The Problem Is Local

Run two comparisons. Open the same page in a private window. Then try it on another device using mobile data. If private mode works, stored site data is the likely trigger. If mobile data works but Wi-Fi fails, a VPN, proxy, or router setting may be altering requests.

Fast Checks That Fix A 400 In Minutes

These steps hit the usual causes and take almost no time. Run them in order and stop as soon as the page loads.

1. Reload Once — Refresh a single time, then move on if it repeats.
2. Clean The URL — Remove everything after “?” and retry.
3. Retype The Domain — Re-enter the base domain to avoid hidden spaces from copy/paste.
4. Try A Private Window — This drops most cookies and clears many repeat 400s.
5. Switch Networks — Toggle VPN off or swap Wi-Fi for mobile data for one test.

Quick Match Table For Symptoms

Symptom	Likely Cause	First Fix
400 after signing in	Corrupt or oversized cookies	Clear cookies for that site
Invalid URL message	Bad characters in the link	Retype the address
Header or cookie too large	Cookie bloat, extension bloat	Clear site data, test without add-ons
400 only on one network	VPN or proxy interference	Retry without VPN
400 only on form submit	Token mismatch or blocked payload	Reload the form, resubmit once

Fixing A 400 HTTP Error In Your Browser And Device

Your browser keeps state that can break a request: cookies, cached redirects, saved DNS records, and extension rules. Reset only what touches the problem site.

Clear Site Data For One Domain

In Chromium browsers, open site settings from the lock icon and clear data for that domain. In Firefox, remove cookies and site data for the domain from privacy settings. Then retry the same page.

1. Open Site Storage — Find the domain’s stored data in site settings or privacy settings.
2. Remove Cookies And Cache — Delete only that site’s data, not your full browsing history.
3. Sign In Fresh — If the error appeared after login, sign in again and retry.

Test Without Add-ons That Modify Pages

Some add-ons block scripts that set security tokens or change headers in ways a site rejects. A clean test is faster than guessing.

• Pause Add-ons For The Site — Disable blockers and script injectors for one test.
• Repeat The Same Action — Click the same button or submit the same form once.
• Reenable One At A Time — Turn add-ons back on until the error returns, then keep that one off.

Reset DNS And Proxy Behavior

If a site moved servers, your device can hang onto a stale DNS entry. A proxy setting can also send traffic in a way that breaks Host header checks.

• Restart The Browser — Fully quit, then reopen.
• Flush DNS Cache — On Windows run ipconfig /flushdns; on macOS flush DNS via Terminal for your version.
• Turn Off Manual Proxies — Disable manual proxy settings for a test and retry.

Fixing 400 Errors From Forms, APIs, And App Requests

A 400 tied to a form submit, upload, or API call often means the server rejected the request body or the headers describing it. Capture the exact request, then reduce it until it passes.

Capture The Failed Request

In a browser, use the Network panel and click the failed request. In Postman, review the request and response tabs. With curl, add -v to see headers and status. Save the response body too, since it often points at the broken field.

1. Save The Payload — Copy the JSON or form body exactly as sent.
2. Check Required Fields — Confirm each required field exists and matches the expected type.
3. Retry With A Minimal Body — Send only required fields, then add others back in small groups.

Fix Content Type And Encoding

Mismatched body format and Content-Type can trigger a 400 before your handler runs. Broken multipart boundaries can do the same for uploads.

• Match Body And Content Type — Use JSON headers for JSON, proper form encoding for forms, and real multipart for files.
• Send UTF-8 Text — Ensure your client encodes text as UTF-8 and the server reads it as UTF-8.
• Avoid Double Encoding — Don’t turn objects into quoted strings by encoding twice.

Handle Token And Session Drift

Some sites throw a 400 when a CSRF token is missing or out of sync with the session cookie. This can happen when a form tab sits open for a long time.

1. Reload The Form Page — Refresh the page so a fresh token is issued.
2. Submit Once — Avoid rapid double clicks that send parallel submits.
3. Review Cookie Flags — Check SameSite and Secure settings if your flow uses redirects.

Server And Edge Reasons A Valid Request Can Still Fail

If users report failures after trying private mode and other networks, check the layers in front of your app: CDN, WAF, reverse proxy, then web server. A 400 can be thrown at any of those points.

Host Header Validation Problems

Many servers reject requests when the Host header does not match a configured domain. This can happen after a DNS change, a load balancer misroute, or a proxy that rewrites Host.

• Confirm DNS Records — Ensure the domain points to the correct edge or origin.
• Check Virtual Host Setup — Confirm the domain is accepted and routed to the right app.
• Test With Curl — Send a request to the origin with the correct Host header.

Header And Body Size Limits

Edge layers enforce limits on header size and request body size. Cookie growth after login is a common trigger. Long URLs and large uploads can also hit limits.

1. Review Size Limits — Check limits in your CDN, proxy, web server, and app server.
2. Reduce Cookie Bloat — Drop unused cookies, shorten values, and keep sessions server-side.
3. Return Clear Errors — If you reject a request, return a readable message like “File too large.”

WAF Rules That Overblock Normal Text

A WAF can block patterns that look like injection. Users can trigger a rule by pasting code snippets or long strings. When that happens, you’ll often see a block log tied to a rule ID.

• Check WAF Logs — Find the rule that blocked the request and confirm the blocked path.
• Tune Or Allowlist Narrowly — Limit the rule to the smallest scope that stops false blocks.
• Add Request IDs — Include a request ID in the response so you can match user reports to logs.

Habits That Stop A 400 From Coming Back

After the immediate fix, put guardrails in place. A recurring 400 http error usually comes from sloppy URL building, ever-growing cookies, or vague validation messages.

Generate URLs With Proper Encoding

Encode query parameters with a URL encoder in your language or library. That prevents broken links when a value includes spaces, emojis, or reserved characters like “&” and “#”.

• Encode Query Values — Use built-in helpers so special characters become safe percent-encoded values.
• Keep URLs Short — Use POST for large payloads instead of stuffing data into a query string.
• Validate Inputs Early — Reject bad characters client-side before sending a request.

Keep Cookies Small And Purposeful

Cookies are sent with every request to that domain. When you pile on tracking and feature flags, you raise the odds of hitting header limits. If you need large session data, store it server-side and keep the cookie to an ID.

1. Expire Old Cookies — Remove stale cookies as features change.
2. Avoid Large Values — Keep tokens and IDs short and rotate them safely.
3. Measure After Login — Track header size in tests so surprises don’t hit production.

To load the page, clear site data after a clean URL and private-window test. For site owners, start first at edge logs for size limits, Host rejects, and WAF blocks.