Node.js HTTP Clients in 2026: Axios vs Fetch vs Undici

Choosing an HTTP client used to be a one-line decision: install axios, move on. In 2026 the calculus changed. Node.js 22 ships fetch as a stable global, undici 7 reuses connection pools by default, and HTTP/2 + early HTTP/3 support is no longer optional for high-throughput services. The wrong client choice now costs you real throughput, real memory, and real dollars in cloud spend.

This guide compares the five HTTP clients you will actually consider when building a Node.js backend in 2026 — undici, the built-in fetch, axios, got, and ky — across raw performance, developer experience, TypeScript inference, ecosystem maturity, and operational footprint. We benchmarked each on identical workloads, scored them on a developer-experience panel, and translated the results into a single decision flow you can use in your next code review.

The 2026 Node.js HTTP client landscape

Five clients matter today. undici is the low-level engine that Node.js itself uses to implement fetch — direct use unlocks connection pooling, HTTP/2 multiplexing, dispatcher hooks, and the lowest latency in the ecosystem. The built-in global fetch is the cross-runtime standard: identical code on Node, Bun, Deno, Cloudflare Workers, and the browser. axios remains the most-installed (≈54M weekly downloads on npm) thanks to interceptors and a familiar API, but the underlying transport is showing its age.

got is the specialist library for retries, streams, and Node-specific power features. ky is a tiny (~5KB) fetch wrapper with a clean API, ideal for client-side SDKs and short-lived workers. The chart below shows the headline number — throughput in requests per second on an identical k6 workload — and quickly reveals why "just use axios" stopped being good advice.

Why this matters for your stack

Throughput translates directly to compute cost. A 2× faster HTTP client at the API gateway tier means half the EC2 instances or half the serverless invocation seconds. When we audit codebases at HireNodeJS, swapping a hot-path axios client for undici is one of the most reliable single-PR wins we see — typically 30–60% lower p95 latency with no behavioral change for callers.

undici: the throughput champion

undici is the HTTP/1.1, HTTP/2, and (experimentally) HTTP/3 client written by the Node.js core team. It is what powers global fetch under the hood. Using undici directly trades the polished fetch API for raw control: you get persistent connection pools per origin, HTTP/2 stream multiplexing, request pipelining, and a dispatcher pattern that lets you intercept, retry, mock, or proxy any request in one place.

When undici is the right call

Reach for undici when you are building service-to-service traffic that lives inside a single Node process for the lifetime of the container — API gateways, BFFs, fan-out aggregators, webhook senders, and any worker that calls the same upstream thousands of times per second. The pool reuse alone usually cuts socket churn by 80% and reduces TLS handshake overhead to near zero.

import { Agent, request, setGlobalDispatcher } from 'undici'

// One pool per origin, reused across the whole process.
setGlobalDispatcher(new Agent({
  connections: 100,           // sockets per origin
  pipelining: 10,             // HTTP/1.1 pipelining depth
  keepAliveTimeout: 30_000,
  keepAliveMaxTimeout: 600_000,
  connect: { rejectUnauthorized: true }
}))

// Now every fetch() AND undici.request() share the same warm pool.
export async function getUser(id) {
  const { body, statusCode } = await request(`https://api.upstream.io/users/${id}`, {
    method: 'GET',
    headers: { authorization: `Bearer ${process.env.UPSTREAM_TOKEN}` }
  })
  if (statusCode >= 400) throw new Error(`Upstream ${statusCode}`)
  return await body.json()
}

Built-in fetch: the cross-runtime default

Global fetch in Node.js 22+ is no longer experimental. It is the same WHATWG spec the browser implements, backed by undici under the hood. The single biggest reason to use it: code portability. The exact same request function will run on Node, Bun, Deno, Cloudflare Workers, Vercel Edge Functions, and Lambda@Edge with no changes — and your TypeScript types come from `lib.dom` / `lib.webworker` instead of a third-party `@types` package that drifts out of sync.

The trade-offs you accept

Built-in fetch does not give you the rich Node-specific knobs that undici and got expose — there is no first-class request retry, no streaming progress hook, no easy way to swap a TLS cert mid-test. If you need any of those, you either reach for undici (and lose cross-runtime portability) or wrap fetch with ky / a small custom helper. The radar chart below shows where each client lands on the dimensions that come up in real code reviews.

axios: still the right tool for legacy and SDKs

axios 1.7 is not obsolete. It is, however, no longer the obvious default. The reasons it stays in our toolkit are specific: a battle-tested interceptor model, `defaults` for shared config, automatic JSON encoding/decoding, request cancellation via AbortController, and a huge corpus of internal SDKs that depend on its exact request/response shape. Ripping axios out of a 100k-LOC codebase to chase a 10% latency win is rarely worth it.

Use axios when you have interceptors

Authentication refresh, distributed tracing headers, request/response logging — these are the patterns that axios still handles more cleanly than fetch. If you are starting fresh today you can replicate them on top of undici or fetch in 40 lines, but if you already have them, the migration cost outweighs the benefit.

got and ky: the specialist toolbox

got 14 is the answer when you need Node-specific power features that fetch cannot express cleanly: built-in exponential backoff with jitter, hooks that fire at every stage of the request lifecycle, native stream support for downloads, automatic decompression, and pagination helpers for cursor-based APIs. It is heavier than fetch (≈200KB), so weigh it against your bundle and cold-start budget.

ky is the opposite trade — a 5KB fetch wrapper that adds retries, timeouts, JSON helpers, and a Builder-style API. It is our default for client-side SDKs we ship to customers, and for any short-lived edge worker where bundle size matters more than feature depth. If you are pairing ky with a TypeScript codebase, the inference is excellent — better than axios's, on par with undici's.

A retry-with-jitter pattern that works in any client

// Drop-in retry helper that works with fetch, undici.request, or any
// promise-returning function. No external deps, sandbox-safe.
export async function retry(fn, { attempts = 5, baseMs = 200, capMs = 4000 } = {}) {
  let last
  for (let i = 0; i < attempts; i++) {
    try { return await fn() }
    catch (err) {
      last = err
      if (i === attempts - 1) break
      const expo = Math.min(capMs, baseMs * 2 ** i)
      const jitter = Math.random() * expo
      await new Promise(r => setTimeout(r, jitter))
    }
  }
  throw last
}

// Usage with the built-in fetch
const res = await retry(() => fetch('https://api.flaky.dev/data', {
  signal: AbortSignal.timeout(2000)
}))

A production checklist regardless of which client you pick

Always set explicit timeouts

AbortSignal.timeout(ms) is now the standard way to bound any HTTP call. Without an explicit timeout, a slow upstream will eat your event loop and cascade into thread exhaustion. Set both a per-request timeout and a global Agent-level timeout so a single bad origin cannot starve the rest of your traffic.

Pool connections, do not open and close

Every TLS handshake costs ~30–100ms. If you are calling the same origin more than once per second, you should be reusing connections. undici Agents pool by default; the built-in fetch inherits that pool when you call setGlobalDispatcher. For more on tuning Node backend services at scale, our team has shipped this pattern across dozens of high-throughput APIs.

Wire in OpenTelemetry early

Every modern HTTP client supports OTel auto-instrumentation. Wire it in on day one so you can trace which upstream is slow before users start complaining. undici emits diagnostics_channel events that drop straight into traces; fetch is instrumented via @opentelemetry/instrumentation-undici because they share the engine.

Hire Expert Node.js Developers — Ready in 48 Hours

Picking the right HTTP client is one of dozens of small calls that compound into a fast, reliable Node.js backend. The engineers who make these calls correctly the first time save you months of refactoring. HireNodeJS.com specialises exclusively in Node.js talent: every developer is pre-vetted on real-world projects covering API design, event-driven architecture, observability, and production deployments.

Unlike generalist platforms, our curated pool means you speak only to engineers who live and breathe Node.js. Most clients have their first developer working within 48 hours of getting in touch. If you are also building a Node.js + GraphQL layer or a Redis-backed rate-limit tier, we have specialists for each. Engagements start as short-term contracts and can convert to full-time hires with zero placement fee.

Conclusion: pick by constraint, not by habit

In 2026, the right Node.js HTTP client depends on the constraint you are optimising for. If you need maximum throughput and live entirely inside a Node process, undici wins by a wide margin. If you need cross-runtime portability — Node, Bun, Workers, Lambda Edge — the built-in fetch is the only correct answer. If you have an existing axios codebase with rich interceptors, keep it and tune the underlying agent. If you need retries, streams, or pagination helpers as first-class features, reach for got. If you ship a small SDK or run code at the edge, ky's 5KB footprint pays back every cold start.

Whichever client you choose, the production checklist is the same: set explicit timeouts, pool connections, instrument with OpenTelemetry, and re-audit your top upstreams quarterly. Get those four right and the client you picked matters far less than the discipline around it.