Turning JavaScript Data into HTTP Messages

Axios does not send a JavaScript object merely because the object exists in application memory. It first has to decide what that object means on the wire. This chapter follows Axios’s translation paths for JSON, query parameters, URL-encoded forms, multipart FormData, files, streams, and parsed responses, so a caller can choose a representation deliberately and recognize when a custom serializer or limit is needed.

The distinction matters because the same application value can produce very different requests. A plain object may become a JSON document. With a different content type, it may become repeated URL-encoded fields or multipart parts. A URLSearchParams object is already a request representation. A file or stream is not a tree that Axios should recursively inspect. The transformation is governed by payload type, headers, runtime capability, and server expectations.

The same object can mean several wire formats

JSON is the default object contract

Axios’s default request transform treats an ordinary object as a JSON payload unless another supported representation is indicated. It sets the JSON content type when needed and serializes the object before the adapter receives it. This is why a call that posts { name: 'Ada' } can remain short: the application supplies structured data, and Axios performs the routine conversion to a JSON string.

The default is useful because JSON is common and easy for both sides to inspect. It is not a universal statement about what an object should mean. If the receiving endpoint expects form fields, a JSON document may be syntactically valid but semantically wrong. The content type is therefore a control input to the transform, not just a label added after the body has already been decided.

Axios also preserves values that already represent a transport-friendly body. Array buffers, buffers, streams, files, blobs, and readable streams are not turned into JSON. A URLSearchParams value is converted to its string form and receives a URL-encoded content type. These branches protect the meaning of binary and stream data: treating a file as an ordinary object would lose the boundary between application data and bytes.

URL-encoded bodies are structured text with server conventions

When the request content type is application/x-www-form-urlencoded, Axios can serialize an object into URL-encoded fields. The result is text, but the field naming convention carries structure. Flat arrays may be repeated with a key such as arr[]; nested arrays and objects can use bracket paths; null values and undefined values follow the serializer’s rules.

The receiving server must decode those conventions in a compatible way. A server parser that understands nested bracket notation can reconstruct an object, while another parser may treat the brackets as literal characters or flatten the fields. Axios can produce the encoded message, but it cannot control the parser on the other side. The correct representation is therefore a shared API contract between the client and server.

The distinction between a query string and a URL-encoded body is also important. Both use URL-style encoding, but one is appended to the request URL and the other occupies the request body. Axios uses the params option for query data and the data option for the body. Keeping them separate makes the intended location visible and prevents a filter from being confused with a submitted resource.

Query parameters are serialized before the adapter sees the URL

A request such as:

api.get('/search', {
  params: {
    query: 'axios',
    page: 2,
  },
});

uses Axios’s query serializer to turn structured values into the URL. Existing query parameters are preserved and new parameters are appended. Nested values and arrays are rendered according to Axios’s conventions, and callers can replace the whole serializer or supply a custom encoder.