400 Bad Request: Request Header Or Cookie Too Large

You see "400 Bad Request" or "400 Bad Request — Request Header Or Cookie Too Large" — the server received something from the browser it could not read, most often an oversized or corrupted cookie for that one site.

Common signs of this issue

• The page shows "400 Bad Request" or "400 Bad Request — Request Header Or Cookie Too Large" instead of your site.
• You see "Your browser sent a request that this server could not understand" in plain text.
• The error follows you around one site in one browser, but the same site works in a private window or on your phone.
• It started after being logged in to the site, its admin area, or several subdomains for a long time.
• Only one link fails, and its address contains odd characters, a stray percent sign, or a very long string of text.
• An upload or form submission fails with a 400 while the rest of the site works.

Safe checks you can do yourself

None of these require sharing passwords with anyone.

• Open the same page in a private or incognito window. If it loads there, the problem is almost certainly your browser's cookies or cache for that site, not the website itself.
• Clear cookies for just that site rather than everything. In Chrome, click the icon to the left of the address, open the cookies or site data option, and delete the stored data for that domain. In Safari, go to Settings, Privacy, then Manage Website Data and remove the domain. In Firefox, click the padlock and choose Clear cookies and site data. Menu names shift between versions, so look for the equivalent wording.
• Reload the page after clearing. If you were logged in, you will need to log in again. That is expected.
• Check the address bar for typos, spaces, doubled slashes, or a lone % sign. A malformed link copied from an email or document is a common cause of a one-page 400.
• Temporarily disable browser extensions, especially ad blockers, privacy tools, and coupon or shopping add-ons, and try again. Some extensions add headers or rewrite requests in ways a strict server rejects.
• If the error only appears when uploading, try a smaller file. Very large uploads are usually rejected with other errors such as 413, but some servers and plugins return 400. See upload max filesize exceeded for the WordPress side.
• If you see "The plain HTTP request was sent to HTTPS port", the site is being reached with http:// on a port meant for https. Try the https:// address; if the problem persists, it is a server or redirect setting for your host.
• Ask a customer or colleague to try the page. If they also get a 400 on a fresh browser, the problem is on the server side, and you should note the exact URL and time for your host.

What this usually means

A 400 means the server looked at what the browser sent and decided it was malformed or too big to process. Unlike most errors in this series, the cause is usually on the visitor's side. Every time your browser asks a site for a page, it sends along all the cookies that site has stored — logins, preferences, analytics and marketing tags. When those pile up past the server's size limit, or one of them becomes corrupted, the server refuses with "Request Header Or Cookie Too Large". That wording comes from nginx, a very common web server, and similar limits exist on Apache, Cloudflare, and others.

Sites that use many subdomains, many tracking or chat tools, or long login sessions are the most likely to hit this, because cookies set for the main domain are sent to every part of it. Clearing that one site's cookies fixes it instantly for the person affected. If many customers see it, though, something on the site is setting too many or oversized cookies — often a plugin, a marketing script, or a loop that adds a new cookie on every page — and that needs fixing at the source, or the error will keep coming back.

The other causes are narrower. A broken link with invalid characters produces a 400 on that address only. Some firewalls return 400 when they dislike the shape of a request. And a site whose server header limits were set unusually low will reject perfectly normal traffic. Those server-side cases are for your host to adjust. If you are seeing a blanket error on every page for everyone, start with 500 Internal Server Error or 403 Forbidden instead, since a true site-wide 400 is rare.

What not to do

• Don't clear every cookie in your browser as a first step. You will be logged out of everything, and clearing one site is enough.
• Don't assume your site is down for everyone. Check in a private window or on another device before panicking.
• Don't raise server header limits as a fix for one visitor's cookie problem. Find out why the cookies got so large instead.
• Don't keep resubmitting a form that returns 400. Check the file size or the data you are sending first.
• Don't ignore reports from several customers. One person with a bad cookie is normal; many means the site is causing it.

When to get help

It is time for help when the 400 comes back for the same people after they clear cookies, when multiple customers report it, or when it hits checkout, logins, or forms that bring in business. At that point the site itself is producing oversized cookies, rejecting valid requests through a firewall rule, or running with header limits set too low, and that is a server and site configuration job rather than a browser one. Someone who can see the actual request headers and server logs can pinpoint which cookie or rule is responsible without guesswork on a live site.

Glenn at WebsiteSelfHelp tracks down stubborn 400 Bad Request and cookie-size errors for small business websites. Send the page address and what the error says, and he will give you a straight answer on whether it is a browser quirk or a site fix, and what that fix would involve — nothing to log in to just to ask.

Frequently asked questions

Related free guides