Fetch API: Browser Support, Features, Limitations

What is the Fetch API?

The Fetch API is a JavaScript interface defined by the WHATWG Fetch Standard for making HTTP network requests from the browser. It exposes a global fetch() method that returns a Promise resolving to a Response object, plus the Headers, Request, Response, and Body interfaces for shaping payloads.

Which browsers does the Fetch API support?

The Fetch API ships by default in every current Chromium browser, Firefox, and Safari. Internet Explorer never added support, and a few legacy mobile builds did not ship it either.

What are the key features of the Fetch API?

The Fetch API replaces XMLHttpRequest with a small, Promise-friendly surface that lines up with service workers, streams, and modern security defaults. The features below are the ones you reach for most often in production code.

• Promise-based fetch(): The global fetch(input, init) call returns a Promise that resolves to a Response object as soon as the server sends headers, even on a 404 or 500. Use response.ok or response.status to branch on success.
• Request and Response objects: Both interfaces are first-class values you can clone, pass to a service worker, or store in a Cache. A Request carries the URL, method, headers, body, and credentials policy; a Response wraps the status, headers, and body.
• Body methods: response.text(), response.json(), response.blob(), response.arrayBuffer(), and response.formData() each return a Promise. Each method drains the body once, so call clone() first if you need to read it twice.
• Headers interface: new Headers() exposes get, set, append, has, delete, and an iterable entries() view. The Fetch spec auto-lowercases header names, so the Headers object normalizes the case differences XMLHttpRequest left to the caller.
• Request cancellation with AbortController: Pass controller.signal to fetch through the signal option and call controller.abort() to cancel an in-flight request. AbortController works in Chrome 66+, Edge 16+, Firefox 57+, and Safari 11.1+.
• Streaming responses: response.body is a ReadableStream, so you can consume bytes as they arrive without buffering the full payload. This is the basis for streamed JSON parsers, server-sent event polyfills, and progressive image decoders.
• Credentials and CORS modes: The init object accepts credentials ("omit", "same-origin", "include") and mode ("cors", "no-cors", "same-origin", "navigate"). The defaults match the modern web: credentials default to same-origin, mode defaults to cors.

How do you check if a browser supports the Fetch API?

Run a one-line feature-detection check at the top of your script and load the whatwg-fetch polyfill on browsers that fail it. Five steps cover the full path from detection to verified output.

• Open DevTools console: Load any page in the target browser, press F12 (or Cmd+Option+I on macOS), and switch to the Console tab.
• Probe window.fetch: Type typeof window.fetch and press Enter. The console prints "function" on supported browsers and "undefined" on Internet Explorer or older Safari.
• Check AbortController: Type typeof window.AbortController. A "function" result confirms the browser supports request cancellation, which lines up with Chrome 66+, Edge 16+, Firefox 57+, and Safari 11.1+.
• Add the polyfill: If fetch is undefined, load whatwg-fetch with a script tag (or import "whatwg-fetch" in a bundler) and load a Promise polyfill before it for IE 11. The polyfill installs window.fetch with the same call signature.
• Confirm with a real call: Paste the snippet below into the console on the same page. The handler logs "Fetch ready" with the response body when the API works, and a clear warning when it does not.

function isFetchSupported() {
    return typeof window !== "undefined"
        && typeof window.fetch === "function"
        && typeof window.Promise === "function";
}

if (isFetchSupported()) {
    fetch("/api/health", { credentials: "same-origin" })
        .then((response) => {
            if (!response.ok) {
                throw new Error("Bad status: " + response.status);
            }
            return response.json();
        })
        .then((data) => console.log("Fetch ready, server said:", data))
        .catch((error) => console.warn("Fetch error:", error.message));
} else {
    console.warn("Fetch API missing - load whatwg-fetch polyfill first");
}

If the console reports a CORS error instead of a network error, fetch is supported but the server is missing the Access-Control-Allow-Origin header. Switch the request to a same-origin URL to confirm the API itself.

What are the known issues with the Fetch API?

The Fetch API is stable, but a handful of behaviors surprise developers who came from XMLHttpRequest or jQuery.ajax. Most cross-browser bugs trace back to these gaps.

• HTTP errors do not reject: A 404 or 500 response still resolves the Promise. Check response.ok inside the first .then and throw if the status is not in the 200 range, otherwise the catch handler never runs on real server failures.
• Internet Explorer is unsupported: IE 5.5 through 11 do not expose window.fetch. Any bundle that calls fetch() without the whatwg-fetch polyfill throws ReferenceError on the first call and breaks the page.
• No native timeout option: The Fetch API has no timeout setting. Wire AbortController to a setTimeout that calls controller.abort() if you need to cap the request, since long requests otherwise hang until the server closes the connection.
• Limited upload progress: The Fetch API does not expose XHR-style upload.onprogress events. Use a ReadableStream request body and count bytes as you write to track upload progress, or fall back to XMLHttpRequest for large file uploads.
• Streaming uploads are partial: Sending a ReadableStream as the request body works in Chrome 105+ over HTTP/2, but Firefox and Safari still buffer the full body before sending. Plan your wire protocol around the slowest target.
• Credentials default surprise: Older Fetch implementations defaulted credentials to omit. Modern browsers default to same-origin, which means cookies flow on same-origin calls but not cross-origin. Set credentials: "include" explicitly for cross-origin auth.
• Body can only be read once: Calling response.json() and then response.text() on the same Response throws. Call response.clone() before the first read if downstream code needs a second pass.
• Mixed-content blocks fetch: A page served over HTTPS cannot fetch() an HTTP URL. The browser blocks the request without firing the catch handler in some builds, so test mixed-content paths early.

In my experience, the silent failure that costs the most production time is the "errors do not reject" rule. Wrap every fetch in a helper that throws on !response.ok before returning the parsed body, and your retry, logging, and alert paths all start working the way you expect.

Citations

All Fetch API version numbers and platform notes in this guide come from these primary sources:

• WHATWG Fetch Standard: fetch.spec.whatwg.org
• MDN Web Docs - Fetch API: developer.mozilla.org/en-US/docs/Web/API/Fetch_API
• MDN Web Docs - Window.fetch(): developer.mozilla.org/en-US/docs/Web/API/Window/fetch
• MDN Web Docs - Using Fetch: developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
• MDN Web Docs - AbortController: developer.mozilla.org/en-US/docs/Web/API/AbortController
• Wikipedia - Fetch API: en.wikipedia.org/wiki/Fetch_API
• Chrome for Developers - Streaming requests with the fetch API: developer.chrome.com/docs/capabilities/web-apis/fetch-streaming-requests
• WebKit Blog - Web APIs and WebKit-specific changes: webkit.org/blog/category/standards
• Mozilla Hacks - This API is so Fetching!: hacks.mozilla.org/2015/03/this-api-is-so-fetching
• whatwg-fetch polyfill: github.com/JakeChampion/fetch