JavaScript

Axios vs fetch: cuándo usar cada uno y qué cambia de verdad

13 may 2026

Escucha este artículo Google español (es-ES)

Hay comparaciones que se explican fatal porque se convierten en un debate de bandos. Axios vs fetch suele caer en eso.

Y en realidad la pregunta útil no es cuál es mejor. La pregunta útil es: qué necesitas resolver y cuánto quieres abstraer.

Los dos sirven para hacer peticiones HTTP. Los dos pueden convivir con async/await. Los dos pueden funcionar perfectamente bien en una app real. Pero no ofrecen la misma experiencia de uso ni las mismas ventajas.

Si lo miras desde trabajo diario, mantenimiento y complejidad de proyecto, la decisión se vuelve mucho más clara.

La diferencia corta: fetch es nativo, Axios añade comodidad

La forma más simple de explicarlo es esta:

fetch es una API nativa
Axios es una librería externa

Eso ya cambia bastante.

Con fetch, no necesitas instalar nada. Ya viene en navegadores modernos y hoy también está muy presente en entornos modernos de servidor.

Con Axios, añades una dependencia, pero a cambio ganas una capa más cómoda para trabajar con peticiones, respuestas, errores y configuración compartida.

No parece mucha diferencia hasta que empiezas a repetir llamadas, headers, tokens, validaciones y manejo de errores por toda la app.

La diferencia más visible: cómo llega el JSON

Este es el primer punto donde casi todo el mundo nota la diferencia.

Con Axios

import axios from 'axios';

async function getUsers() {
  const response = await axios.get('/api/users');
  return response.data;
}

Con fetch

async function getUsers() {
  const response = await fetch('/api/users');
  return response.json();
}

Con Axios, el cuerpo útil suele estar directamente en response.data.

Con fetch, primero recibes un objeto Response y luego decides cómo leerlo: json(), text(), blob(), etc.

Eso no es malo. De hecho, a veces es mejor porque te da más control. Pero sí implica que fetch es más explícito y Axios más cómodo.

Otro punto clave: el manejo de errores HTTP

Aquí hay una diferencia importante que mucha gente descubre tarde.

Con fetch, una respuesta 404 o 500 no lanza error automáticamente. La promesa solo falla por problemas de red o interrupciones más bajas de nivel.

Eso obliga a comprobar response.ok manualmente:

async function getUsers() {
  const response = await fetch('/api/users');

  if (!response.ok) {
    throw new Error(`Error HTTP: ${response.status}`);
  }

  return response.json();
}

En Axios, los códigos HTTP fuera del rango 2xx normalmente sí entran en catch:

import axios from 'axios';

async function getUsers() {
  try {
    const response = await axios.get('/api/users');
    return response.data;
  } catch (error) {
    console.error('Error en la petición', error);
    throw error;
  }
}

Ese detalle cambia bastante la sensación de uso en proyectos con muchas llamadas.

Cuándo usar fetch

Yo elegiría fetch cuando el proyecto pide menos dependencia y más sencillez base.

Por ejemplo:

si el proyecto es pequeño o mediano
si solo vas a hacer unas pocas peticiones
si no quieres añadir una librería extra por algo que ya existe nativamente
si prefieres controlar tú mismo el flujo de respuestas y errores
si trabajas en entornos donde fetch ya está bien integrado

También tiene mucho sentido cuando quieres mantener el stack más ligero y más cercano a la plataforma.

Dicho de otra forma: si el problema HTTP de tu app es relativamente simple, fetch suele ser más que suficiente.

Cuándo usar Axios

Yo elegiría Axios cuando el proyecto necesita comodidad repetible y una capa HTTP más preparada.

Por ejemplo:

si tienes muchas peticiones repartidas por la app
si necesitas enviar tokens o headers comunes constantemente
si quieres interceptores para auth, refresh token o logging
si necesitas una instancia centralizada del cliente HTTP
si el equipo ya tiene utilidades montadas alrededor de Axios

En un proyecto grande, esa comodidad deja de ser un detalle y se convierte en ahorro real de tiempo.

La gran ventaja de Axios: menos fricción en apps grandes

La parte fuerte de Axios no es que haga magia. La parte fuerte es que te evita repetir trabajo.

Un ejemplo muy típico es crear una instancia compartida:

import axios from 'axios';

export const api = axios.create({
  baseURL: 'https://api.miapp.com',
  headers: {
    'Content-Type': 'application/json',
  },
});

Y a partir de ahí usar api.get(), api.post(), api.put(), etc.

Si además necesitas interceptores para meter un token o capturar errores globales, Axios se vuelve especialmente cómodo.

La gran ventaja de fetch: menos peso y menos dependencia

La fuerza de fetch está justo en el lado contrario: no dependes de nadie para empezar.

Eso tiene varias ventajas reales:

menos dependencias en el proyecto
menos superficie de mantenimiento
menos riesgo asociado a librerías externas
una API estándar que cualquier desarrollador frontend debería entender

En un proyecto donde las peticiones son simples, meter Axios puede ser perfectamente válido, pero también puede ser más herramienta de la que realmente necesitas.

Pros y contras rápidos

Pros de fetch

no requiere instalación
es estándar y nativo
reduce dependencias
ofrece control explícito sobre la respuesta

Contras de fetch

hay más código manual para manejar errores HTTP
tienes que parsear JSON con response.json()
para flujos repetidos puedes terminar creando tus propias abstracciones

Pros de Axios

API muy cómoda para uso diario
response.data simplifica muchísimo el trabajo habitual
mejor experiencia para centralizar configuración
interceptores muy útiles en apps medianas o grandes

Contras de Axios

añade una dependencia externa
aumenta un poco el peso del proyecto
puede ser innecesario si el uso HTTP es muy básico

Mi regla práctica

Si el proyecto es pequeño, el flujo HTTP es sencillo y quieres mantenerlo nativo: usa fetch.

Si el proyecto empieza a crecer, tienes auth, muchas llamadas, configuración compartida y lógica repetida alrededor de HTTP: Axios suele compensar.

No porque fetch no pueda hacerlo. Puede. Pero a veces terminarías construyendo a mano parte de la comodidad que Axios ya trae resuelta.

Entonces, ¿cuál elegiría yo?

Mi respuesta corta sería:

fetch para simplicidad y stack ligero
Axios para ergonomía y repetición a escala

Si hoy tuviera que empezar una app pequeña, iría probablemente con fetch.

Si sé desde el principio que habrá autenticación, muchas llamadas, cliente HTTP compartido y gestión centralizada de errores, me parece totalmente razonable arrancar con Axios.

La clave no es “qué usa más gente”. La clave es qué te hace el código más claro y más mantenible en ese proyecto concreto.

Conclusión

fetch y Axios compiten en el mismo terreno, pero no juegan exactamente la misma partida. Uno apuesta por lo nativo y lo explícito. El otro apuesta por la comodidad y la abstracción práctica.

Elegir bien no va de dogma. Va de volumen de llamadas, repetición, complejidad y mantenimiento. Si partes de ahí, la decisión casi siempre se aclara sola.