In this guide, we'll take a look at how to use XMLHttpRequest
to issue HTTP requests in order to exchange data between the website and a server.
Examples of both common and more obscure use cases for XMLHttpRequest
are included.
To send an HTTP request, create an XMLHttpRequest
object, open a URL, and send the request. After the transaction completes, the object will contain useful information such as the response body and the HTTP status of the result.
function reqListener() {
console.log(this.responseText);
}
const req = new XMLHttpRequest();
req.addEventListener("load", reqListener);
req.open("GET", "http://www.example.org/example.txt");
req.send();
Types of requests
A request made via XMLHttpRequest
can fetch the data in one of two ways, asynchronously or synchronously. The type of request is dictated by the optional async
argument (the third argument) that is set on the XMLHttpRequest.open()
method. If this argument is true
or not specified, the XMLHttpRequest
is processed asynchronously, otherwise the process is handled synchronously. A detailed discussion and demonstrations of these two types of requests can be found on the synchronous and asynchronous requests page. You can't use synchronous requests outside web workers as it freezes the main interface.
Note: The constructor XMLHttpRequest
isn't limited to only XML documents. It starts with "XML" because when it was created the main format that was originally used for asynchronous data exchange was XML.
Handling responses
There are several types of response attributes defined for the XMLHttpRequest()
constructor. These tell the client making the XMLHttpRequest
important information about the status of the response. Some cases where dealing with non-text response types may involve some manipulation and analysis are outlined in the following sections.
Analyzing and manipulating the responseXML property
If you use XMLHttpRequest
to get the content of a remote XML document, the responseXML
property will be a DOM object containing a parsed XML document. This could prove difficult to manipulate and analyze. There are four primary ways of analyzing this XML document:
- Using XPath to address (or point to) parts of it.
- Manually Parsing and serializing XML to strings or objects.
- Using
XMLSerializer
to serialize DOM trees to strings or to files. -
RegExp
can be used if you always know the content of the XML document beforehand. You might want to remove line breaks, if you use RegExp
to scan with regard to line breaks. However, this method is a "last resort" since if the XML code changes slightly, the method will likely fail.
Processing a responseText property containing an HTML document
If you use XMLHttpRequest
to get the content of a remote HTML webpage, the responseText
property is a string containing the raw HTML. This could prove difficult to manipulate and analyze. There are three primary ways to analyze and parse this raw HTML string:
- Use the
XMLHttpRequest.responseXML
property as covered in the article HTML in XMLHttpRequest. - Inject the content into the body of a document fragment via
fragment.body.innerHTML
and traverse the DOM of the fragment. -
RegExp
can be used if you always know the content of the HTML responseText
beforehand. You might want to remove line breaks, if you use RegExp
to scan with regard to line breaks. However, this method is a "last resort" since if the HTML code changes slightly, the method will likely fail.
Handling binary data
Although XMLHttpRequest
is most commonly used to send and receive textual data, it can be used to send and receive binary content. There are several well tested methods for coercing the response of an XMLHttpRequest
into sending binary data. These involve utilizing the overrideMimeType()
method on the XMLHttpRequest
object and is a workable solution.
const req = new XMLHttpRequest();
req.open("GET", url);
req.overrideMimeType("text/plain; charset=x-user-defined");
However, more modern techniques are available, since the responseType
attribute now supports a number of additional content types, which makes sending and receiving binary data much easier.
For example, consider this snippet, which uses the responseType
of "arraybuffer
" to fetch the remote content into a ArrayBuffer
object, which stores the raw binary data.
const req = new XMLHttpRequest();
req.onload = (e) => {
const arraybuffer = req.response;
};
req.open("GET", url);
req.responseType = "arraybuffer";
req.send();
For more examples check out the Sending and Receiving Binary Data page.
Monitoring progress
XMLHttpRequest
provides the ability to listen to various events that can occur while the request is being processed. This includes periodic progress notifications, error notifications, and so forth.
Support for DOM progress
event monitoring of XMLHttpRequest
transfers follows the specification for progress events: these events implement the ProgressEvent
interface. The actual events you can monitor to determine the state of an ongoing transfer are:
progress
-
The amount of data that has been retrieved has changed.
load
-
The transfer is complete; all data is now in the response
const req = new XMLHttpRequest();
req.addEventListener("progress", updateProgress);
req.addEventListener("load", transferComplete);
req.addEventListener("error", transferFailed);
req.addEventListener("abort", transferCanceled);
req.open();
function updateProgress(event) {
if (event.lengthComputable) {
const percentComplete = (event.loaded / event.total) * 100;
} else {
}
}
function transferComplete(evt) {
console.log("The transfer is complete.");
}
function transferFailed(evt) {
console.log("An error occurred while transferring the file.");
}
function transferCanceled(evt) {
console.log("The transfer has been canceled by the user.");
}
Lines 3-6 add event listeners for the various events that are sent while performing a data transfer using XMLHttpRequest
.
Note: You need to add the event listeners before calling open()
on the request. Otherwise the progress
events will not fire.
The progress event handler, specified by the updateProgress()
function in this example, receives the total number of bytes to transfer as well as the number of bytes transferred so far in the event's total
and loaded
fields. However, if the lengthComputable
field is false, the total length is not known and will be zero.
Progress events exist for both download and upload transfers. The download events are fired on the XMLHttpRequest
object itself, as shown in the above sample. The upload events are fired on the XMLHttpRequest.upload
object, as shown below:
const req = new XMLHttpRequest();
req.upload.addEventListener("progress", updateProgress);
req.upload.addEventListener("load", transferComplete);
req.upload.addEventListener("error", transferFailed);
req.upload.addEventListener("abort", transferCanceled);
req.open();
Note: Progress events are not available for the file:
protocol.
Progress events come in for every chunk of data received, including the last chunk in cases in which the last packet is received and the connection closed before the progress event is fired. In this case, the progress event is automatically fired when the load event occurs for that packet. This lets you now reliably monitor progress by only watching the "progress" event.
One can also detect all three load-ending conditions (abort
, load
, or error
) using the loadend
event:
req.addEventListener("loadend", loadEnd);
function loadEnd(e) {
console.log(
"The transfer finished (although we don't know if it succeeded or not).",
);
}
Note there is no way to be certain, from the information received by the loadend
event, as to which condition caused the operation to terminate; however, you can use this to handle tasks that need to be performed in all end-of-transfer scenarios.
Get last modified date
function getHeaderTime() {
console.log(this.getResponseHeader("Last-Modified"));
}
const req = new XMLHttpRequest();
req.open(
"HEAD",
"yourpage.html",
);
req.onload = getHeaderTime;
req.send();
Do something when last modified date changes
Let's create two functions:
function getHeaderTime() {
const lastVisit = parseFloat(
window.localStorage.getItem(`lm_${this.filepath}`),
);
const lastModified = Date.parse(this.getResponseHeader("Last-Modified"));
if (isNaN(lastVisit) || lastModified > lastVisit) {
window.localStorage.setItem(`lm_${this.filepath}`, Date.now());
isFinite(lastVisit) && this.callback(lastModified, lastVisit);
}
}
function ifHasChanged(URL, callback) {
const req = new XMLHttpRequest();
req.open("HEAD" , URL);
req.callback = callback;
req.filepath = URL;
req.onload = getHeaderTime;
req.send();
}
And to test:
ifHasChanged("yourpage.html", function (modified, visit) {
console.log(
`The page '${this.filepath}' has been changed on ${new Date(
nModified,
).toLocaleString()}!`,
);
});
If you want to know if the current page has changed, refer to the article about document.lastModified
.
Cross-site XMLHttpRequest
Modern browsers support cross-site requests by implementing the Cross-Origin Resource Sharing (CORS) standard. As long as the server is configured to allow requests from your web application's origin, XMLHttpRequest
will work. Otherwise, an INVALID_ACCESS_ERR
exception is thrown.
Bypassing the cache
A cross-browser compatible approach to bypassing the cache is appending a timestamp to the URL, being sure to include a "?" or "&" as appropriate. For example:
http://foo.com/bar.html -> http://foo.com/bar.html?12345
http://foo.com/bar.html?foobar=baz -> http://foo.com/bar.html?foobar=baz&12345
As the local cache is indexed by URL, this causes every request to be unique, thereby bypassing the cache.
You can automatically adjust URLs using the following code:
const req = new XMLHttpRequest();
req.open("GET", url + (/\?/.test(url) ? "&" : "?") + new Date().getTime());
req.send(null);
Security
The recommended way to enable cross-site scripting is to use the Access-Control-Allow-Origin
HTTP header in the response to the XMLHttpRequest.
XMLHttpRequests being stopped
If you conclude with an XMLHttpRequest receiving status=0
and statusText=null
, this means the request was not allowed to be performed. It was UNSENT
. A likely cause for this is when the XMLHttpRequest
origin (at the creation of the XMLHttpRequest) has changed when the XMLHttpRequest is subsequently open()
. This case can happen, for example, when one has an XMLHttpRequest that gets fired on an onunload event for a window, the expected XMLHttpRequest is created when the window to be closed is still there, and finally sending the request (in other words, open()
) when this window has lost its focus and another window gains focus. The most effective way to avoid this problem is to set a listener on the new window's DOMActivate
event which is set once the terminated window has its unload
event triggered.
Workers
Setting overrideMimeType
does not work from a Worker
. See Firefox bug 678057 for more details. Other browsers may handle this differently.
Specifications
Browser compatibility
|
Desktop |
Mobile |
|
Chrome |
Edge |
Firefox |
Internet Explorer |
Opera |
Safari |
WebView Android |
Chrome Android |
Firefox for Android |
Opera Android |
Safari on IOS |
Samsung Internet |
XMLHttpRequest |
1 |
12 |
1 |
7 |
≤12.1 |
3 |
4.4 |
18 |
4 |
≤12.1 |
1 |
1.0 |
Using_XMLHttpRequest |
1 |
12 |
1 |
75Implemented via ActiveXObject('Microsoft.XMLHTTP')
|
8 |
1.2 |
≤37 |
18 |
4 |
10.1 |
1 |
1.0 |
abort |
1 |
12 |
1 |
5 |
≤12.1 |
1.2 |
4.4 |
18 |
4 |
≤12.1 |
1 |
1.0 |
abort_event |
1 |
12 |
3.5 |
10 |
≤12.1 |
1.3 |
≤37 |
18 |
4 |
≤12.1 |
1 |
1.0 |
authorization_removed_cross_origin |
No |
No |
111 |
No |
No |
16.1 |
No |
No |
111 |
No |
16.1 |
No |
error_event |
1 |
12 |
1 |
10 |
≤12.1 |
1.3 |
≤37 |
18 |
4 |
≤12.1 |
1 |
1.0 |
getAllResponseHeaders |
1 |
12 |
1Starting from Firefox 49, empty headers are returned as empty strings in case the preference network.http.keep_empty_response_headers_as_empty_string is set to true , defaulting to false . Before Firefox 49 empty headers had been ignored. Since Firefox 50 the preference defaults to true . |
5 |
≤12.1 |
1.2 |
4.4 |
18 |
4Starting from Firefox 49, empty headers are returned as empty strings in case the preference network.http.keep_empty_response_headers_as_empty_string is set to true , defaulting to false . Before Firefox 49 empty headers had been ignored. Since Firefox 50 the preference defaults to true . |
≤12.1 |
1 |
1.0 |
getResponseHeader |
1 |
12 |
1Starting from Firefox 49, empty headers are returned as empty strings in case the preference network.http.keep_empty_response_headers_as_empty_string is set to true , defaulting to false . Before Firefox 49 empty headers had been ignored. Since Firefox 50 the preference defaults to true . |
5 |
8 |
1.2 |
4.4 |
18 |
4Starting from Firefox 49, empty headers are returned as empty strings in case the preference network.http.keep_empty_response_headers_as_empty_string is set to true , defaulting to false . Before Firefox 49 empty headers had been ignored. Since Firefox 50 the preference defaults to true . |
10.1 |
1 |
1.0 |
load_event |
1 |
12 |
1 |
9 |
≤12.1 |
1.3 |
≤37 |
18 |
4 |
≤12.1 |
1 |
1.0 |
loadend_event |
18 |
12 |
5 |
10 |
≤12.1 |
4 |
4.4 |
18 |
5 |
≤12.1 |
3 |
1.0 |
loadstart_event |
1 |
12 |
3.5 |
10 |
≤12.1 |
1.3 |
4.4 |
18 |
4 |
≤12.1 |
1 |
1.0 |
open |
1 |
12 |
1Starting in Firefox 30, synchronous requests on the main thread have been deprecated due to their negative impact on performance and the user experience. Therefore, the async parameter may not be false except in a Worker . |
5 |
8 |
1.2 |
4.4 |
18 |
4Starting in Firefox 30, synchronous requests on the main thread have been deprecated due to their negative impact on performance and the user experience. Therefore, the async parameter may not be false except in a Worker . |
10.1 |
1 |
1.0 |
overrideMimeType |
1 |
12 |
1 |
115Implemented via ActiveXObject
|
≤12.1 |
1.2 |
4.4 |
18 |
4 |
≤12.1 |
1 |
1.0 |
progress_event |
1 |
12 |
1 |
10 |
≤12.1 |
3 |
≤37 |
18 |
4 |
≤12.1 |
1 |
1.0 |
readyState |
1 |
12 |
1 |
7 |
8 |
1.2 |
4.4 |
18 |
4 |
10.1 |
1 |
1.0 |
readystatechange_event |
1 |
12 |
1 |
5 |
9 |
1.2 |
4.4 |
18 |
4 |
10.1 |
1 |
1.0 |
response |
9 |
12 |
6 |
10 |
11.6 |
5.1 |
3 |
18 |
6 |
12 |
5 |
1.0 |
responseText |
1 |
12 |
1 |
5Before Internet Explorer 10, the value of XMLHttpRequest.responseText could be read only once the request was complete. |
8 |
1.2 |
4.4 |
18 |
4 |
10.1 |
1 |
1.0 |
responseType |
31 |
12 |
6 |
10 |
1812–15 |
5.1 |
4.4.3 |
31 |
50 |
1812–14 |
5 |
2.0 |
responseURL |
37 |
14 |
32 |
No |
24 |
8 |
37 |
37 |
32 |
24 |
8 |
3.0 |
responseXML |
1 |
12 |
1Before Firefox 51, an error parsing the received data added a <parsererror> node to the top of the Document and then returned the Document in whatever state it happens to be in. This was inconsistent with the specification. Starting with Firefox 51, this scenario now correctly returns null as per the spec. |
7 |
≤12.1 |
3 |
≤37 |
18 |
4Before Firefox 51, an error parsing the received data added a <parsererror> node to the top of the Document and then returned the Document in whatever state it happens to be in. This was inconsistent with the specification. Starting with Firefox 51, this scenario now correctly returns null as per the spec. |
≤12.1 |
1 |
1.0 |
send |
1 |
12 |
1 |
5 |
8 |
1.2 |
4.4 |
18 |
4 |
10.1 |
1 |
1.0 |
setAttributionReporting |
117 |
117 |
No |
No |
103 |
No |
117 |
117 |
No |
No |
No |
No |
setPrivateToken |
117 |
117 |
No |
No |
103 |
No |
117 |
117 |
No |
No |
No |
No |
setRequestHeader |
1 |
12 |
1 |
5 |
8 |
1.2 |
4.4 |
18 |
4 |
10.1 |
1 |
1.0 |
status |
1 |
12 |
1 |
7Internet Explorer version 5 and 6 supported ajax calls using ActiveXObject() |
8 |
1.2 |
4.4 |
18 |
4 |
10.1 |
1 |
1.0 |
statusText |
1 |
12 |
1 |
7Internet Explorer version 5 and 6 supported ajax calls using ActiveXObject() |
≤12.1 |
1.2 |
4.4 |
18 |
4 |
≤12.1 |
1 |
1.0 |
timeout |
29 |
12 |
12 |
8 |
1712–16 |
7 |
4.4 |
29 |
14 |
1812–16 |
7 |
2.0 |
timeout_event |
29 |
12 |
12 |
8 |
16 |
7 |
4.4 |
29 |
14 |
16 |
7 |
1.0 |
upload |
2 |
12 |
3.5 |
10 |
≤12.1 |
4 |
4.4 |
18 |
4 |
≤12.1 |
3 |
1.0 |
withCredentials |
3 |
12 |
3.5Starting with Firefox 11, it's no longer supported to use the withCredentials attribute when performing synchronous requests. Attempting to do so throws an NS_ERROR_DOM_INVALID_ACCESS_ERR exception. |
10Internet Explorer versions 8 and 9 supported cross-domain requests (CORS) using XDomainRequest . |
12 |
4 |
≤37 |
18 |
4Starting with Firefox 11, it's no longer supported to use the withCredentials attribute when performing synchronous requests. Attempting to do so throws an NS_ERROR_DOM_INVALID_ACCESS_ERR exception. |
12 |
3.2 |
1.0 |
worker_support |
4 |
12 |
3.5 |
10 |
10.6 |
4 |
4 |
18 |
4 |
11 |
5 |
1.0 |
See also