Get to know MDN better
Esta página ha sido traducida del inglés por la comunidad. Aprende más y únete a la comunidad de MDN Web Docs.
This feature is well established and works across many devices and browser versions. It’s been available across browsers since julio de 2015.
* Some parts of this feature may have varying levels of support.
En esta guía le echaremos un vistazo a cómo usar XMLHttpRequest para enviar solicitudes HTTP con el objetivo de intercambiar datos entre el sitio web y el servidor.
Se incluyen ejemplos, tanto para los casos de uso comunes de XMLHttpRequest, como para los más inusuales.
Para enviar una solicitud HTTP, cree un objeto XMLHttpRequest, abra una URL y envíe la solicitud. Una vez que la transacción haya sido completada, el objeto contendrá información útil tal como el cuerpo de la respuesta y el estado HTTP status del resultado.
Una petición realizada a través de XMLHttpRequest puede obtener los datos de una estas dos maneras, de forma asíncrona o sincrónica. El tipo de petición viene dictado por el argumento opcional async (el tercer argumento) que se establece en el método XMLHttpRequest.open(). Si este argumento es true o no se especifica, la XMLHttpRequest se procesa de forma asíncrona, de lo contrario el proceso se realiza de forma síncrona. Una discusión detallada y demostraciones de estos de estos dos tipos de peticiones en la página peticiones síncronas y asíncronas. No utilice solicitudes sincrónicas fuera de los Web Workers.
Nota: A partir de Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 / SeaMonkey 2.27), las peticiones síncronas en el hilo principal han sido marcadas como obsoletas debido a los efectos negativos en la experiencia del usuario.
Nota: La función constructora XMLHttpRequest no se limita a los documentos XML. Comienza con "XML" porque cuando se creó el formato principal que se utilizaba originalmente para el intercambio de datos asíncrono era XML.
Hay varios tipos de atributos de respuesta definidos por la especificación del estándar para el constructor XMLHttpRequest(). Esto le dice al cliente que realiza el XMLHttpRequest información importante sobre el estado de la respuesta. Algunos casos en los que tratar con tipos de respuesta no textuales puede implicar alguna manipulación y análisis como se describen en las siguientes secciones.
Si utiliza XMLHttpRequest para obtener el contenido de un documento XML remoto, la propiedad responseXML será un objeto DOM que contiene un documento XML analizado. Esto podría resultar difícil de manipular y analizar. Principalmente hay cuatro formas de analizar este documento XML:
Nota: XMLHttpRequest ahora puede interpretar HTML por ti utilizando la propiedad responseXML. Lea el artículo sobre HTML en XMLHttpRequest para aprender como hacerlo.
Si usas XMLHttpRequest para obtener el contenido de una página web HTML remota, la propiedad responseText es una cadena que contiene el HTML en bruto. Esto podría resultar difícil de manipular y analizar. Principalmente hay tres tres formas de analizar y parsear esta cadena de HTML en bruto:
Aunque XMLHttpRequest se utiliza normalmente para enviar y recibir datos textuales, puede utilizarse para enviar y recibir contenido binario. Existen varios métodos probados para forzar a la respuesta de un XMLHttpRequest para que envíe datos binarios. Se trata de utilizar la función overrideMimeType() en el objeto XMLHttpRequest y es una solución viable.
Sin embargo, existen técnicas más modernas, ya que el responseType admite ahora una serie de tipos de contenido adicionales, lo que facilita el envío y la recepción de datos binarios.
Por ejemplo, considere este fragmento, que utiliza el responseType de "arraybuffer" para obtener el contenido remoto en un objeto ArrayBuffer que almacena los datos binarios en bruto.
Para ver más ejemplos, consulte la página Envío y recepción de datos binarios
XMLHttpRequest proporciona la capacidad de escuchar varios eventos que pueden ocurrir mientras se procesa la solicitud. Esto incluye notificaciones periódicas del progreso, notificaciones de error, etc.
La implementación para la monitorización de eventos DOM progress de transferencias XMLHttpRequest sigue la especificación de eventos de progreso: estos eventos implementan la interfaz ProgressEvent. Los eventos reales que puedes monitorizar para determinar el estado de una transferencia en curso son:
progressLa cantidad de datos que se han recibido ha cambiado.
loadLa transferencia se ha completado; todos los datos están ahora en el response.
Las líneas 3-6 añaden escuchadores de eventos para los distintos eventos que se envían al realizar una transferencia de datos utilizando XMLHttpRequest.
Nota: Tienes que añadir los escuchadores de eventos antes de llamar a open() en la petición. De lo contrario, los eventos `progress no se dispararán.
El manejador de eventos de progreso, especificado por la función updateProgress() en este ejemplo, recibe el número total de bytes a transferir así como el número de bytes transferidos hasta el momento en los campos total y loaded del evento. Sin embargo, si el campo lengthComputable es falso, la longitud total no se conoce y será cero.
Los eventos de progreso existen tanto para las transferencias de descarga como de subida. Los eventos de descarga se disparan en el propio objeto XMLHttpRequest, como se muestra en el ejemplo anterior. Los eventos de subida se disparan en el objeto XMLHttpRequest.upload, como se muestra a continuación:
Nota: Los eventos de progreso no están disponibles para el protocolo file:.
Nota: A partir de Gecko 9.0, se puede confiar en que los eventos de progreso lleguen para cada trozo de datos recibidos, incluyendo el último trozo en los casos en los que se recibe el último paquete y se cierra la conexión antes de que se dispare el evento de progreso. En este caso, el evento de progreso se dispara automáticamente cuando se produce el evento de carga para ese paquete. Esto te permite ahora monitorizar de forma fiable el progreso observando únicamente el evento "progress".
Nota: A partir de Gecko 12.0, si su evento de progreso es llamado con un responseType de "moz-blob", el valor de la respuesta es un Blob que contiene los datos recibidos hasta el momento.
También se pueden detectar las tres condiciones de finalización de la carga (abort, load, o error) utilizando el evento loadend:
Ten en cuenta que no hay forma de estar seguros, a partir de la información recibida por el evento de la información recibida por el evento loadend, en cuanto a la condición que causó la terminación de la operación; sin embargo, puede utilizar esto para manejar las tareas que deben realizarse en todos los escenarios de fin de transferencia.
Las instancias de XMLHttpRequest pueden utilizarse para enviar formularios de dos maneras:
El uso de la API FormData es el más sencillo y rápido, pero tiene la desventaja de que los datos recogidos no pueden ser stringificados.
Utilizar sólo AJAX es más complejo, pero suele ser más flexible y potente.
El envío de formularios sin la API FormData no necesita de otras APIs para la mayoría de los casos de uso. El único caso en el que necesita una API adicional es si quiere subir uno o más archivos, donde se utiliza la API FileReader.
Un html <form> puede ser enviado de cuatro maneras:
Consideremos ahora el envío de un formulario que contiene sólo dos campos, llamados foo y baz. Si está utilizando el método POST el servidor recibirá una cadena similar a uno de los tres ejemplos siguientes, dependiendo dependiendo del tipo de codificación que esté utilizando:
Método: POST; Tipo de codificación: application/x-www-form-urlencoded (por defecto):
Content-Type: application/x-www-form-urlencoded foo=bar&baz=The+first+line.%0D%0AThe+second+line.%0D%0AMétodo: POST; Tipo de codificación: text/plain:
Content-Type: text/plain foo=bar baz=The first line. The second line.Método: POST; Tipo de codificación: multipart/form-data:
Content-Type: multipart/form-data; boundary=---------------------------314911788813839 -----------------------------314911788813839 Content-Disposition: form-data; name="foo" bar -----------------------------314911788813839 Content-Disposition: form-data; name="baz" The first line. The second line. -----------------------------314911788813839--Sin embargo, si utiliza el método GET, se añadirá a la URL una cadena como la siguiente:
?foo=bar&baz=The%20first%20line.%0AThe%20second%20line.Todos estos efectos son realizados automáticamente por el navegador web cada vez que se envía un <form>. Si quieres realizar los mismos efectos usando JavaScript tiene que tiene que instruir al intérprete sobre todo. Por lo tanto, la forma de enviar formularios en puro AJAX es demasiado complejo para ser explicado aquí en detalle. Por esta razón, aquí colocamos un completo (aunque didáctico) framework, capaz de utilizar las cuatro formas de enviar, y de subir archivos:
Para probar esto, cree una página llamada register.php (que es la que se encuentra en el atributo action de estos formularios de muestra), y ponga lo siguiente contenido minimalista:
La sintaxis para activar este script es:
Nota: Este framework utiliza la API FileReader para transmitir las cargas de archivos. Este es un API reciente y no está implementada en IE9 o inferiores. Por esta razón, la carga sólo en AJAX se considera una técnica experimental. Si no necesita subir archivos binarios, este framework funciona bien en la mayoría de los navegadores.
Nota: La mejor manera de enviar contenido binario es a través de ArrayBuffers o Blobs junto con con el método send() y posiblemente el método readAsArrayBuffer() de la API FileReader. Pero, como el objetivo de este script es trabajar con un stringifiable de datos en bruto, utilizamos el método sendAsBinary() junto con el método readAsBinaryString() de la API FileReader. Por lo tanto, el script anterior tiene sentido sólo cuando se trata de archivos pequeños. Si no tiene intención de de cargar contenido binario, considere utilizar la API FormData.
Nota: El método no estándar sendAsBinary se considera obsoleto a partir de Gecko 31 (Firefox 31 / Thunderbird 31 / SeaMonkey 2.28) y se eliminará pronto. En su lugar se puede utilizar el método estándar send(Blob data).
El constructor FormData permite recopilar un conjunto de pares clave/valor para enviarlos mediante XMLHttpRequest. Su uso principal es para enviar datos de formularios, pero también puede utilizarse independientemente de un formulario para transmitir datos clave del usuario. Los datos transmitidos tienen el mismo formato que el método del formulario para enviar los datos, si el tipo de codificación del formulario se establece como "multipart/form-data". Los objetos FormData pueden utilizarse de varias maneras con un método XMLHttpRequest. Para ver ejemplos y explicaciones de cómo se puede utilizar FormData con XMLHttpRequests, consulte la sección Utilizando objetos FormData. Para fines didácticos aquí hay una traducción del ejemplo anterior transformado para usar la API FormData. Nótese la brevedad del código:
Nota: Como hemos dicho, los objetos FormData no son objetos stringifiable. Si quieres transformar en string los datos enviados, utiliza el ejemplo anterior en puro-AJAX. Tenga en cuenta también que, aunque en este ejemplo hay algunos campos file <input>, cuando se envía un formulario a través de la API FormData tampoco es necesario utilizar la API FileReader: los archivos se cargan y suben automáticamente.
Vamos a crear dos funciones:
Y para probar:
Si quieres saber si la página actual ha cambiado, por favor, lee el artículo sobre document.lastModified.
Los navegadores modernos admiten las peticiones cross-site implementando el estándar Recursos compartidos de origen-cruzado (CORS). Siempre que el servidor esté configurado para permitir las peticiones desde el origen de su aplicación web, XMLHttpRequest funcionará. En caso contrario, se lanzará una excepción INVALID_ACCESS_ERR.
Un enfoque compatible con todos los navegadores para evitar la caché es añadir una marca de tiempo a a la URL, asegurándose de incluir un "?" o "&" según corresponda. Por ejemplo:
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&12345Como la caché local se indexa por URL, esto hace que cada petición sea única, por lo que salta la caché.
Puedes ajustar automáticamente las URLs usando el siguiente código:
La manera recomendada para habilitar el cross-site scripting es utilizar la cabecera cabecera HTTP Access-Control-Allow-Origin en la respuesta al XMLHttpRequest.
Si concluye con una XMLHttpRequest que recibe status=0 y statusText=null, significa que no se ha permitido realizar la petición. Era UNSENT. Una causa probable de esto es cuando el origen XMLHttpRequest (en la creación de la XMLHttpRequest) ha cambiado cuando el XMLHttpRequest es posterior a open(). Este caso puede darse, por ejemplo, cuando se tiene un XMLHttpRequest que se dispara en un evento onunload para una ventana, el esperado XMLHttpRequest se crea cuando la ventana a cerrar sigue ahí, y finalmente enviar la petición (en otras palabras, open()) cuando esta ventana ha perdido su foco y otra ventana toma el foco. La forma más eficaz de evitar este problema es es establecer una escucha en el evento activate de la nueva ventana que se activa una vez que la ventana terminada tenga su evento unload disparado.
Establecer overrideMimeType no funciona desde un Worker. Ver Error 678057 en Firefox para más detalles. Otros navegadores pueden manejar esto de manera diferente.
| XMLHttpRequest # interface-xmlhttprequest |
Enable JavaScript to view this browser compatibility table.
This page was last modified on 4 dic 2025 by MDN contributors.
Your blueprint for a better internet.
Visit Mozilla Corporation’s not-for-profit parent, the Mozilla Foundation.
Portions of this content are ©1998–2026 by individual mozilla.org contributors. Content available under a Creative Commons license.