Axios v1.20.0 earns its place when one client must span runtimes
Axios v1.20.0 gives browser and server code one Promise-based request API across XHR, Fetch, and Node HTTP adapters. Instances carry a base URL, defaults, and shared headers; interceptors can add authentication or inspect responses; AbortController cancels work. Axios also serializes JSON, URL-encoded bodies, and multipart forms, reports transfer progress, and includes TypeScript definitions. That is more machinery than a basic fetch() call, yet it can remove a fair amount of repeated glue from an application that uses several of those features.
The source is smaller than its API surface suggests. Our checkout contained 466 files, about 41,264 lines of source, and occupied 3.6 MB before dependencies. Axios has no server process and stores no application data. Your code imports a library and sends requests to services you choose. The operational burden therefore sits in configuration: define instances by trust domain, keep authorization headers scoped to the right host, choose an adapter intentionally when behavior matters, and make cancellation and error handling part of each call path.
Axios v1.20.0 leaves timeout and response caps to the caller
Axios v1.20.0 defaults the request timeout to 0, which means a stalled request can wait indefinitely. The README tells production users to set one. Its Node and Fetch content limits also default to unlimited values, and the security notice warns that a small compressed response can expand until the process runs out of memory. These choices preserve compatibility and avoid surprising limits on legitimate transfers. They also mean a shared client instance should carry timeouts, response caps, request-size caps, redirect rules, and secret-header policy before feature teams start using it.
Repository setup was direct in our clean container: npm installed 626 packages in 20 seconds and used 199 MB on disk. The build then passed in 17 seconds. Those are contributor-checkout figures, not the dependency cost of adding the published Axios package to an application. The checkout's .npmrc disables lifecycle scripts from every dependency as a supply-chain measure. That also suppresses Axios's own prepare hook, so contributors must run the documented Husky rebuild once if they want local Git hooks.
What happened when we ran it
Our run at commit fede1d1 completed installation in 20 seconds and the build in 17 seconds. Npm audit found 0 known vulnerabilities at every listed severity. The source scan found 8 CI workflow files and a tests directory, with no Dockerfile. Our measurement setup was a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. The repository mechanics therefore worked through compilation, while the full test result needs a narrower reading.
Tests ended with exit 1 after 135 seconds. Vitest reported 1,054 passed and 8 failed out of 1,062, across 56 passing test files and 2 failing files. The log tail repeatedly says a test exceeded 5,000 ms. It does not identify an application bug, a missing system package, or a single shared cause for all 8 failures. The defensible finding is that the suite did not pass in our stated sandbox. Maintainers should rerun the named files and preserve the complete failure output before deciding what to change.
Interceptor order and adapter choice can change request behavior
Axios v1.20.0 runs request interceptors in reverse registration order and response interceptors in registration order. A synchronous request interceptor that throws calls its paired rejection handler; if that handler returns normally, Axios may continue with the last valid config. The README advises throwing or returning a rejected Promise when validation must block a request. These details matter in authentication and policy code. A tidy interceptor chain can become unsafe when its order is assumed rather than tested, especially after several packages register their own handlers.
Adapter differences deserve the same attention. The Fetch adapter arrived in v1.7.0, custom Fetch support in v1.12.0, and Node HTTP/2 support in v1.13.0. The README still labels HTTP/2 experimental and says redirects are unsupported there. Our 135-second test run covered 1,062 cases overall, but 8 failures prevent treating the checkout as clean. Test the adapter your deployment selects, including proxy, redirects, progress, cancellation, compression limits, and any custom Request or Response constructors.
Open Node reports concern agents, proxies, and error serialization
Open issue 11145 reports that 25 requests failed concurrently and exhausted the Node heap when AxiosError.toJSON() serialized config containing shared http.Agent and https.Agent objects. The reporter says versions from 1.2.0 through the then-current v1.x code were affected. Open issue 11176 describes a different production concern: custom CA options from httpsAgent were reportedly lost while tunneling through a plain HTTP proxy in versions 1.17.0 and 1.18.0. Both reports are specific enough to turn into upgrade checks.
Maintenance activity is current. GitHub recorded 109,195 stars, 88 combined issues and pull requests, and a last push on September 1, 2026. Release v1.20.0 was published on August 24 with runtime-option hardening, Node socket-memory work, XHR fixes, and tooling updates. Our audit found 0 known vulnerabilities in the 626-package source checkout, but that result does not close behavior reports. Axios is mature and well documented; its wide runtime surface rewards teams that pin versions and test the paths they actually use.