XMLHttpRequest

XMLHttpRequest lets browser scripts exchange data with an HTTP server without replacing the current document. The interface was first associated with Microsoft browser technology and was later implemented across browsers and standardized as a Web API; its name reflects an early emphasis on XML rather than a restriction to that format.¹ A typical request creates an object, calls open() with an HTTP method and URL, assigns event handlers, and invokes send(). The server response can be read through properties such as responseText, responseXML, or the more general response, whose interpretation is selected with responseType. The API is therefore a transport interface, not a data format or server-side technology.

The request lifecycle is exposed through state changes, completion events, and error events. The readyState values move from UNSENT and OPENED through response-header and loading stages to DONE, while onload, onerror, ontimeout, and onabort help code handle different outcomes.² HTTP status must be checked separately: a completed transport operation can still produce an unsuccessful status such as 404 or 500. Callers can set request headers with setRequestHeader(), inspect response headers, configure a timeout, and cancel work with abort(). Progress events provide a lesser-used way to monitor downloads and, where supported, uploads. Asynchronous requests are the normal mode because synchronous main-thread requests can block rendering and user interaction.

XMLHttpRequest is constrained by the browser's same-origin policy, so a script normally cannot read responses from another origin unless that origin grants access through Cross-Origin Resource Sharing (CORS).³ A cross-origin request may trigger a preflight OPTIONS request when its method or headers are not considered simple; the server must return suitable CORS response headers, and credentials require additional explicit permission. These checks govern browser access to the response, not whether a packet can reach a server. Requests also follow HTTP semantics, including methods, status codes, redirects, caching, and authentication rules defined by HTTP specifications.⁴ Developers must still defend against injection, validate untrusted responses, and use HTTPS; XMLHttpRequest does not make transferred data trustworthy.

XMLHttpRequest supports more than background JSON loading, including binary responses, upload progress, response-header inspection, and incremental processing while a response is arriving. Setting responseType to values such as arraybuffer, blob, or document changes how the browser exposes the result.² The API can also send form data and participate in credentialed requests, although cookies and other credentials are governed by origin and server policy. Synchronous use is restricted or discouraged in several modern contexts, particularly on the main thread, and the Fetch API is generally preferred for new code because it offers promises, streams, and a more composable model.^{1 5} XMLHttpRequest nevertheless remains relevant for older libraries, upload progress interfaces, and codebases that depend on its event model.

Asynchronous request

A request whose network activity does not block the browser's main execution thread while the program waits for a response.

CORS

Cross-Origin Resource Sharing, a mechanism using HTTP headers to permit controlled browser access to resources on another origin.

readyState

The XMLHttpRequest property describing the request's current lifecycle stage.

responseType

A property that specifies how the browser should expose the received response, such as text, JSON, a Blob, or an ArrayBuffer.

Same-origin policy

A browser security rule that restricts scripts from reading resources associated with different origins unless an allowed mechanism applies.