ERR_ABORTED website error explained

ERR_ABORTED is the Chrome error that appears when a request or navigation was cancelled before it finished, rather than failing because of a network problem. Unlike a connection reset or a timeout, an aborted request often did nothing wrong: the browser, the page, or the user deliberately stopped it, and in many cases that is exactly the intended behaviour. The difficulty is telling harmless cancellations apart from the ones that point to a real problem.

What it means

When a resource is fetched, something has to control when that fetch stops. ERR_ABORTED is the error the browser reports for that stop. It shows up in the developer tools network panel as a request with a status such as cancelled or (aborted), and the most common sources are ones you can spot immediately:

• The user navigated away or pressed the stop button mid-request, which the browser reports as that request being aborted.
• The page navigated to a new URL, so old in-flight requests were abandoned.
• JavaScript called an abort mechanism on a fetch, which rejects the promise with an abort-style error rather than a network failure.
• An image or script fell out of view or out of use and the browser cancelled a low-priority fetch.

But ERR_ABORTED can also be a symptom of a real site fault: a service worker that mishandles a request, or a resource that the page decides it no longer needs, can both surface as an abort.

The common causes

The largest bucket of aborted requests requires no action. When a visitor clicks a link or reloads while a page is still loading, the previous page's scripts, images and calls are abandoned, and Chrome marks them aborted. This is normal and expected for most sites.

The second bucket is JavaScript-triggered. Code that cancels an in-flight request, for example a search box that aborts the previous query when a new keystroke arrives, correctly produces an abort. A service worker can also cause this, especially if it fetches a resource with a signal that gets aborted, or fails to pass the placeholder signal from the original request, leaving a background request running or reporting an error the client then sees as aborted. When a service worker intercepts navigation and its response promise rejects or is aborted, the navigation itself fails with an abort-style error.

A third possibility is genuinely worth investigating. Aborting repeatedly on one page often means the page is re-requesting the same resource over and over because a dependency changed, or a resource load is being superseded each time by a newer one, which can hint at a loop in how the page or its scripts trigger fetches.

How to fix it

Start by opening the developer tools network panel and finding the aborted entry, then decide which category it falls into before changing anything.

• Filter for status aborted and sort by whether the aborts happened while the page was still loading or user navigation was in progress. If they coincide with navigation, they are expected and safe to ignore.
• For a script-triggered abort, confirm the code intended to cancel the fetch. If it did, the abort is correct behaviour and needs no fix.
• For a service worker, inspect the fetch handler. Ensure any fetch you create passes the original request's signal so that when the page aborts, the inner fetch aborts too, and verify you call the response method with a real response and not a rejected promise, since a rejection is what turns into a hard navigation error.
• If the same element aborts constantly with no navigation and no script cause, that is the suspicious case. Look for a dependency that changes every time and a re-request loop, or check whether the resource is being superseded by a newer request in a tight cycle.

Once the cause of the repeat cancellations is removed, the aborts should shrink to the harmless navigation-driven set. If the page still will not load, see website not loading and the blank page guide, and for genuine connection failures rather than cancellations, ERR_CONNECTION_RESET is the related read.