axios-cache-adapter and axios-cache-interceptor are both libraries designed to add HTTP caching capabilities to Axios requests in JavaScript applications. They enable developers to avoid redundant network calls by storing and reusing responses based on configurable cache strategies, improving performance and reducing server load. Both integrate directly with Axios but differ significantly in architecture, API design, and maintenance status.
Both axios-cache-adapter and axios-cache-interceptor aim to solve the same core problem: caching HTTP responses in Axios-based applications to reduce redundant network requests, improve perceived performance, and lower backend load. However, they take fundamentally different approaches — one is a legacy solution built on Axios adapters, while the other is a modern, actively maintained library leveraging Axios interceptors. Let’s break down what this means in practice.
axios-cache-adapter is officially deprecated. Its npm page and GitHub repository clearly state: "This project is deprecated. Please use axios-cache-interceptor instead." No new features are being added, and only critical fixes might be considered. Using it in new projects introduces long-term risk.
axios-cache-interceptor is the recommended successor, actively developed and aligned with current Axios versions. It’s designed to work seamlessly with Axios v0.27 and above, including support for modern features like request aborting and proper TypeScript definitions.
💡 Bottom line: For any new project, start with
axios-cache-interceptor. Only consideraxios-cache-adapterif you’re stuck maintaining old code that hasn’t been migrated yet.
Axios supports two extension points: adapters (which handle the actual HTTP transport) and interceptors (which hook into request/response flows). The two packages use these differently.
axios-cache-adapter replaces Axios’s default adapter entirely:
// axios-cache-adapter: replaces the adapter
import axios from 'axios';
import { setupCache } from 'axios-cache-adapter';
const cache = setupCache({ maxAge: 15 * 60 * 1000 }); // 15 minutes
const api = axios.create({
adapter: cache.adapter
});
const response = await api.get('/users');
This approach works but tightly couples caching logic to the transport layer, making it harder to compose with other adapters (e.g., for mocking or custom backends).
axios-cache-interceptor uses standard Axios interceptors, which plug into the existing request/response pipeline without replacing core behavior:
// axios-cache-interceptor: uses interceptors
import axios from 'axios';
import { setupCache } from 'axios-cache-interceptor';
const api = setupCache(axios.create());
const response = await api.get('/users', {
cache: { ttl: 15 * 60 * 1000 } // 15 minutes
});
This is more flexible — you can still use custom adapters, and caching becomes just one layer in your Axios configuration stack.
How you tell each library what to cache and for how long also differs.
axios-cache-adapter relies on its own configuration object passed at instance creation or per-request:
// axios-cache-adapter: custom cache config
const response = await api.get('/posts', {
cache: {
maxAge: 10000, // milliseconds
exclude: { query: false }
}
});
It doesn’t natively respect standard HTTP caching headers like Cache-Control or ETag unless you implement custom logic.
axios-cache-interceptor leans heavily into standard HTTP caching semantics. By default, it respects Cache-Control, Expires, and ETag headers from responses. You can also override with explicit TTL:
// axios-cache-interceptor: HTTP-aware + overrides
const response = await api.get('/posts', {
cache: {
ttl: 10000, // fallback if no HTTP headers
interpretHeader: true // default: uses Cache-Control
}
});
This means your frontend cache can automatically align with your backend’s caching policy — a big win for consistency.
Both libraries support manual cache clearing, but their APIs differ.
axios-cache-adapter exposes a global cache object with methods like del():
// axios-cache-adapter: manual invalidation
await api.get('/user/123');
// Later...
cache.del('/user/123'); // removes cached entry
axios-cache-interceptor provides more granular control via the axios instance itself:
// axios-cache-interceptor: instance-based invalidation
await api.get('/user/123');
// Later...
api.storage.remove('/user/123'); // or use api.cache.delete()
Additionally, axios-cache-interceptor supports automatic cache updates using stale-while-revalidate strategies and conditional requests (If-None-Match) when ETags are present — reducing stale data without blocking UI updates.
axios-cache-adapter offers basic logging via the debug option, but debugging cache hits/misses often requires inspecting internal structures.
axios-cache-interceptor includes built-in debug tools:
const api = setupCache(axios.create(), {
debug: true // logs cache decisions to console
});
It also exposes clear metadata on responses:
const res = await api.get('/data');
console.log(res.cached); // true | false | 'stale'
This makes it far easier to verify caching behavior during development.
You need to fetch user stats every 30 seconds but avoid hammering the server if data hasn’t changed.
axios-cache-interceptorstale-while-revalidate and ETag-based conditional requests out of the box:setInterval(async () => {
const res = await api.get('/stats', {
cache: { ttl: 30_000, staleWhileRevalidate: true }
});
updateUI(res.data);
}, 30_000);
Your old app uses axios-cache-adapter, and you can’t rewrite everything at once.
axios-cache-adapter during incremental migration| Feature | axios-cache-adapter | axios-cache-interceptor |
|---|---|---|
| Status | ❌ Deprecated (do not use in new projects) | ✅ Actively maintained |
| Integration Method | Replaces Axios adapter | Uses Axios interceptors |
| HTTP Header Support | Limited (requires custom logic) | Full Cache-Control, ETag, Expires |
| Cache Metadata | Minimal | Rich (res.cached, debug logs) |
| Modern Axios Support | Uncertain (last tested on older versions) | Built for Axios v0.27+ |
| Stale-While-Revalidate | Not supported | ✅ Supported |
If you’re starting a new frontend project that uses Axios and needs caching:
→ Use axios-cache-interceptor. It’s the official, modern, and sustainable choice.
If you’re working on an existing codebase using axios-cache-adapter:
→ Plan a migration to axios-cache-interceptor. The effort pays off in maintainability, correctness, and alignment with web standards.
Caching is hard to get right — using a well-maintained, HTTP-compliant library reduces bugs and keeps your app fast without reinventing the wheel.
Choose axios-cache-adapter only if you are maintaining a legacy codebase that already depends on it. The package is officially deprecated as of 2023, no longer accepts new features, and recommends migration to axios-cache-interceptor. It should not be used in new projects due to lack of active support and compatibility risks with future Axios versions.
Choose axios-cache-interceptor for all new projects requiring Axios caching. It is actively maintained, built specifically for modern Axios (v0.27+), uses Axios interceptors instead of adapters for cleaner integration, and offers more flexible cache control through standard HTTP headers and fine-grained configuration options.
Caching adapter for axios. Store request results in a configurable store to prevent unneeded network requests.
Adapted from superapi-cache by @stephanebachelier
Using npm
npm install --save axios-cache-adapter
Or bower
bower install --save axios-cache-adapter
Or from a CDN like unpkg.com
<script type="text/javascript" src="https://unpkg.com/axios-cache-adapter"></script>
Important note: Only GET request results are cached by default. Executing a request using any method listed in exclude.methods will invalidate the cache for the given URL.
You can instantiate the axios-cache-adapter on its own using the setupCache() method and then attach the adapter manually to an instance of axios.
// Import dependencies
import axios from 'axios'
import { setupCache } from 'axios-cache-adapter'
// Create `axios-cache-adapter` instance
const cache = setupCache({
maxAge: 15 * 60 * 1000
})
// Create `axios` instance passing the newly created `cache.adapter`
const api = axios.create({
adapter: cache.adapter
})
// Send a GET request to some REST api
api({
url: 'http://some-rest.api/url',
method: 'get'
}).then(async (response) => {
// Do something fantastic with response.data \o/
console.log('Request response:', response)
// Interacting with the store, see `localForage` API.
const length = await cache.store.length()
console.log('Cache store length:', length)
})
You can use the setup() method to get an instance of axios pre-configured with the axios-cache-adapter. This will remove axios as a direct dependency in your code.
// Import dependencies
import { setup } from 'axios-cache-adapter'
// Create `axios` instance with pre-configured `axios-cache-adapter` attached to it
const api = setup({
// `axios` options
baseURL: 'http://some-rest.api',
// `axios-cache-adapter` options
cache: {
maxAge: 15 * 60 * 1000
}
})
// Send a GET request to some REST api
api.get('/url').then(async (response) => {
// Do something awesome with response.data \o/
console.log('Request response:', response)
// Interacting with the store, see `localForage` API.
const length = await api.cache.length()
console.log('Cache store length:', length)
})
After setting up axios-cache-adapter with a specific cache configuration you can override parts of that configuration on individual requests.
import { setup } from 'axios-cache-adapter'
const api = setup({
baseURL: 'https://httpbin.org',
cache: {
maxAge: 15 * 60 * 1000
}
})
// Use global instance config
api.get('/get').then((response) => {
// Do something awesome with response
})
// Override `maxAge` and cache URLs with query parameters
api.get('/get?with=query', {
cache: {
maxAge: 2 * 60 * 1000, // 2 min instead of 15 min
exclude: { query: false }
}
})
.then((response) => {
// Do something beautiful ;)
})
Note: Not all instance options can be overridden per request, see the API documentation at the end of this readme
You can allow axios-cache-adapter to cache the results of a request using (almost) any HTTP method by modifying the exclude.methods list.
import { setup } from 'axios-cache-adapter
const api = setup({
baseURL: 'https://httpbin.org',
cache: {
exclude: {
// Only exclude PUT, PATCH and DELETE methods from cache
methods: ['put', 'patch', 'delete']
}
}
})
api.post('/post').then((response) => {
// POST request has been cached \o/
})
Note: the request method is not used in the cache store key by default, therefore with the above setup, making a GET or POST request will respond with the same cache.
You can give a localforage instance to axios-cache-adapter which will be used to store cache data instead of the default in memory store.
Note: This only works client-side because localforage does not work in Node.js
import localforage from 'localforage'
import memoryDriver from 'localforage-memoryStorageDriver'
import { setup } from 'axios-cache-adapter'
// `async` wrapper to configure `localforage` and instantiate `axios` with `axios-cache-adapter`
async function configure () {
// Register the custom `memoryDriver` to `localforage`
await localforage.defineDriver(memoryDriver)
// Create `localforage` instance
const forageStore = localforage.createInstance({
// List of drivers used
driver: [
localforage.INDEXEDDB,
localforage.LOCALSTORAGE,
memoryDriver._driver
],
// Prefix all storage keys to prevent conflicts
name: 'my-cache'
})
// Create `axios` instance with pre-configured `axios-cache-adapter` using a `localforage` store
return setup({
// `axios` options
baseURL: 'http://some-rest.api',
// `axios-cache-adapter` options
cache: {
maxAge: 15 * 60 * 1000,
store: forageStore // Pass `localforage` store to `axios-cache-adapter`
}
})
}
configure().then(async (api) => {
const response = await api.get('/url')
// Display something beautiful with `response.data` ;)
})
You can give a RedisStore instance to axios-cache-adapter which will be used to store cache data instead of the default in memory store.
Note: This only works server-side
const { setup, RedisStore } = require('axios-cache-adapter')
const redis = require('redis')
const client = redis.createClient({
url: 'REDIS_URL',
})
const store = new RedisStore(client)
const api = setup({
// `axios` options
baseURL: 'http://some-rest.api',
// `axios-cache-adapter` options
cache: {
maxAge: 15 * 60 * 1000,
store // Pass `RedisStore` store to `axios-cache-adapter`
}
})
const response = await api.get('/url')
You can give a RedisDefaultStore instance to axios-cache-adapter which will be used to store cache data in Redis using the default commands instead of hash commands.
Note: This only works server-side
const { setup, RedisDefaultStore } = require('axios-cache-adapter')
const redis = require('redis')
const client = redis.createClient({
url: 'REDIS_URL',
})
const store = new RedisDefaultStore(client, {
prefix: 'namespace_as_prefix' // optional
})
const api = setup({
// `axios` options
baseURL: 'http://some-rest.api',
// `axios-cache-adapter` options
cache: {
maxAge: 15 * 60 * 1000,
store // Pass `RedisDefaultStore` store to `axios-cache-adapter`
}
})
const response = await api.get('/url')
When a response is served from cache a custom response.request object is created with a fromCache boolean.
// Import dependencies
import assert from 'assert'
import { setup } from 'axios-cache-adapter'
// Create `axios` instance with pre-configured `axios-cache-adapter`
const api = setup({
cache: {
maxAge: 15 * 60 * 1000
}
})
// Wrap code in an `async` function
async function exec () {
// First request will be served from network
const response = await api.get('http://some-rest.api/url')
// `response.request` will contain the origin `axios` request object
assert.ok(response.request.fromCache !== true)
// Second request to same endpoint will be served from cache
const anotherResponse = await api.get('http://some-rest.api/url')
// `response.request` will contain `fromCache` boolean
assert.ok(anotherResponse.request.fromCache === true)
}
// Execute our `async` wrapper
exec()
You can tell axios-cache-adapter to read stale cache data when a network error occurs using the readOnError option.
readOnError can either be a Boolean telling cache adapter to attempt reading stale cache when any network error happens or a Function which receives the error and request objects and then returns a Boolean.
By default axios-cache-adapter clears stale cache data automatically, this would conflict with activating the readOnError option, so the clearOnStale option should be set to false.
import { setup } from 'axios-cache-adapter'
const api = setup({
cache: {
// Attempt reading stale cache data when response status is either 4xx or 5xx
readOnError: (error, request) => {
return error.response.status >= 400 && error.response.status < 600
},
// Deactivate `clearOnStale` option so that we can actually read stale cache data
clearOnStale: false
}
})
// Make a first successful request which will store the response in cache
api.get('https://httpbin.org/get').then(response => {
// Response will not come from cache
assert.ok(response.request.fromCache !== true)
})
// Let's say that the stored data has become stale (default 15min max age has passed)
// and we make the same request but it results in an internal server error (status=500)
api.get('https://httpbin.org/get').then(response => {
// Response is served from cache
assert.ok(response.request.fromCache === true)
// We can check that it actually served stale cache data
assert.ok(response.request.stale === true)
}).catch(err => {
// Will not execute this because stale cache data was returned
// If the attempt at reading stale cache fails, the network error will be thrown and this method executed
})
Note: Passing a function to readOnError is a smarter thing to do as you get to choose when a stale cache read should be attempted instead of doing it on all kind of errors
Using the default invalidation method, a cache entry will be invalidated if a request is made using one of the methods listed in exclude.methods.
async function defaultInvalidate (config, request) {
const method = request.method.toLowerCase()
if (config.exclude.methods.includes(method)) {
await config.store.removeItem(config.uuid)
}
}
You can customize how axios-cache-adapter invalidates stored cache entries by providing a custom invalidate function.
import { setup } from 'axios-cache-adapter'
// Create cached axios instance with custom invalidate method
const api = setup({
cache: {
// Invalidate only when a specific option is passed through config
invalidate: async (config, request) => {
if (request.clearCacheEntry) {
await config.store.removeItem(config.uuid)
}
}
}
})
// Make a request that will get stored into cache
api.get('https://httpbin.org/get').then(response => {
assert.ok(response.request.fromCache !== true)
})
// Wait some time
// Make another request to same end point but force cache invalidation
api.get('https://httpbin.org/get', { clearCacheEntry: true }).then(response => {
// Response should not come from cache
assert.ok(response.request.fromCache !== true)
})
maxAgeWhen you set the readHeaders option to true, the adapter will try to read cache-control or expires headers to automatically set the maxAge option for the given request.
import assert from 'assert'
import { setup } from 'axios-cache-adapter'
const api = setup({
cache: {
// Tell adapter to attempt using response headers
readHeaders: true,
// For this example to work we disable query exclusion
exclude: { query: false }
}
})
// Make a request which will respond with header `cache-control: max-age=60`
api.get('https://httpbin.org/cache/60').then(response => {
// Cached `response` will expire one minute later
})
// Make a request which responds with header `cache-control: no-cache`
api.get('https://httpbin.org/response-headers?cache-control=no-cache').then(response => {
// Response will not come from cache
assert.ok(response.request.fromCache !== true)
// Check that query was excluded from cache
assert.ok(response.request.excludedFromCache === true)
})
Note: For the cache-control header, only the max-age, no-cache and no-store values are interpreted.
Create a cache adapter instance. Takes an options object to configure how the cached requests will be handled,
where they will be stored, etc.
// Options passed to `setupCache()`.
{
// {Number} Maximum time for storing each request in milliseconds,
// defaults to 15 minutes when using `setup()`.
maxAge: 0,
// {Number} Maximum number of cached request (last in, first out queue system),
// defaults to `false` for no limit. *Cannot be overridden per request*
limit: false,
// {Object} An instance of localforage, defaults to a custom in memory store.
// *Cannot be overridden per request*
store: new MemoryStore(),
// {String|Function} Generate a unique cache key for the request.
// Will use request url and serialized params by default.
key: req => req.url + serializeQuery(req.params),
// {Function} Invalidate stored cache. By default will remove cache when
// making a request with method not `GET`, `POST`, `PUT`, `PATCH` or `DELETE` query.
invalidate: async (cfg, req) => {
const method = req.method.toLowerCase()
if (method !== 'get') {
await cfg.store.removeItem(cfg.uuid)
}
},
// {Object} Define which kind of requests should be excluded from cache.
exclude: {
// {Array} List of regular expressions to match against request URLs.
paths: [],
// {Boolean} Exclude requests with query parameters.
query: true,
// {Function} Method which returns a `Boolean` to determine if request
// should be excluded from cache.
filter: null,
// {Array} HTTP methods which will be excluded from cache.
// Defaults to `['post', 'patch', 'put', 'delete']`
// Any methods listed will also trigger cache invalidation while using the default `config.invalidate` method.
//
// Note: the HEAD method is always excluded (hard coded).
// the OPTIONS method is ignored by this library as it is automatically handled by browsers/clients to resolve cross-site request permissions
methods: ['post', 'patch', 'put', 'delete']
},
// {Boolean} Clear cached item when it is stale.
clearOnStale: true,
// {Boolean} Clear all cache when a cache write error occurs
// (prevents size quota problems in `localStorage`).
clearOnError: true,
// {Function|Boolean} Determine if stale cache should be read when a network error occurs.
readOnError: false,
// {Boolean} Determine if response headers should be read to set `maxAge` automatically.
// Will try to parse `cache-control` or `expires` headers.
readHeaders: false,
// {Boolean} Ignore cache, will force to interpret cache reads as a `cache-miss`.
// Useful to bypass cache for a given request.
ignoreCache: false,
// {Function|Boolean} Print out debug log to console.
debug: false
}
setupCache() returns an object containing the configured adapter, the cache store and the config that is applied to this instance.
Create an axios instance pre-configured with the cache adapter. Takes an options object to configure the cache and
axios at the same time.
{
cache: {
// Options passed to the `setupCache()` method
}
// Options passed to `axios.create()` method
}
All the other parameters will be passed directly to the axios.create method.
setup() returns an instance of axios pre-configured with the cache adapter.
The cache store is conveniently attached to the axios instance as instance.cache for easy access.
RedisStore allow you to cache requests on server using redis.
Create a RedisStore instance. Takes client (RedisClient) and optional hashKey (name of hashSet to be used in redis).
// Using redis client https://github.com/NodeRedis/node_redis
// We have tested it with node_redis v.2.8.0 but it's supposed to work smoothly with the comming releases.
const redis = require("redis")
const client = redis.createClient()
new RedisStore() returns an instance of RedisStore to be passed to setupCache() as store in config object.
Using the same object definition as the setup method you can override cache options for individual requests.
api.get('https://httpbin.org/get', {
cache: {
// Options override
}
})
All options except limit and store can be overridden per request.
Also the following keys are used internally and therefore should not be set in the options: adapter, uuid, acceptStale.
npm run build
Webpack is used to build umd versions of the library that are placed in the dist folder.
cache.jscache.min.jscache.node.jscache.node.min.jsA different version of axios-cache-adapter is generated for node and the browser due to how Webpack 4 uses a target to change how the UMD wrapper is generated using global or window. If you are using the library in node or in your front-end code while using a module bundler (Webpack, rollup, etc) the correct version will be picked up automatically thanks to the "main" and "browser" fields in the package.json.
axios-cache-adapter is developped in ES6+ and uses async/await syntax. It is transpiled to ES5 using babel with preset-env.
Tests are executed using karma.
To launch a single run tests using ChromeHeadless:
npm test
To launch tests in watch mode in Chrome for easier debugging with devtools:
npm run watch
axios-cache-adapter was designed to run in the browser. It does work in nodejs using the in memory store. But storing data in memory is not the greatests idea ever.
You can give a store to override the in memory store but it has to comply with the localForage API and localForage does not work in nodejs for very good reasons that are better explained in this issue.
The better choice if you want to use axios-cache-adapter server-side is to use a redis server with a RedisStore instance as explained above in the API section.
MIT © Carl Ogren