Fix response data evicted from inspector cache in Chrome

TL;DR#

Request content was evicted from inspector cache means Chromium cannot return the stored body for that inspected request. It does not establish that your application received an empty response. Check the application's actual data, then capture a fresh request to a file with curl or Node if you need the full payload. Validate the saved content; HTTP 200 alone does not prove that the download is complete, valid JSON or the expected file.

The Stack Overflow report describes a React/Axios request for a file embedded as base64. The Network panel shows a 200 status, but its preview displays:

failed to load response data request content was evicted from inspector cache

Smaller responses displayed successfully in that report. Its reported size is an observation from that application, not a universal Chrome threshold. The useful diagnostic is the distinction between receiving data and retaining a copy for inspection.

Why it happens#

Chromium's InspectorNetworkAgent source contains the exact eviction message in its response-body retrieval method. When the recorded resource says its content has been evicted, that method returns an inspection error rather than the body. This is why a request row and its status can remain useful while the Response or Preview contents are unavailable.

The Chrome DevTools Protocol definition exposes separate total and per-resource buffers for preserving network payloads. The inspection copy has its own retention constraints. Do not infer an Axios response-size setting, a Node server limit or a broken base64 encoder merely from this message.

This distinction was reproduced on 13 October 2026 using headless Chromium 153.0.8010.12, Playwright 1.63.0 and Node 24.20.0 in Docker. A local server returned a generated JSON fixture of 65,564 bytes. JavaScript consumed the entire body, parsed it and computed the same SHA256 hash as the server fixture. At the same time, a deliberately small per-resource inspector buffer caused this exact protocol error:

BEFORE INSPECTOR ERROR cdpSession.send: Protocol error (Network.getResponseBody): Request content was evicted from inspector cache

Only the configured per-resource capture budget was enlarged for a fresh capture; the response data stayed identical. Inspector retrieval then succeeded. These were explicit laboratory settings, not measured Chrome defaults. The test exercised the browser protocol, not a click-through of the DevTools interface, and did not reproduce the original application's Axios code.

Fix#

1. Inspect the application's result before changing its transport. Put a breakpoint immediately after your Axios request resolves, or examine the data returned to your fetch handler. Check the expected fields and types. For a base64 field, distinguish a missing field from an empty string and from a non-empty string your UI has not rendered. Logging a small length or type is more useful than dumping the entire encoded file into the console.

   If your browser console instead reports that access was blocked by CORS, follow the CORS response-header diagnosis. A curl request succeeding cannot establish that browser JavaScript is allowed to read the response. That is a different failure from inspector eviction.

2. Copy the request, then save a fresh response outside the inspector. Chrome's Network reference documents Copy as cURL, PowerShell, fetch and Node.js fetch. Choose the form matching your terminal. A Bash command's quoting and continuation characters are not automatically valid PowerShell syntax.

   For a GET endpoint that needs no additional request options, this PowerShell example prompts for your actual URL and uses the curl executable explicitly:

   powershell

   $requestUrl = Read-Host 'URL of the GET request'
   curl.exe --fail --silent --show-error --output response.json $requestUrl
   if ($LASTEXITCODE -ne 0) { throw 'Response download failed' }
   Get-Item -LiteralPath 'response.json' | Select-Object Length

   For an authenticated request or a POST, retain the correct method, body and required headers from your own request instead of replacing it with that simple GET. Keep copied credentials local. Do not include them in an issue report or share a command containing private cookies.

   The curl manual documents output-to-file and HTTP-error handling. Using the explicit output option saves the body without depending on PowerShell text-redirection behaviour. The local reproduction used Linux curl 8.5.0; the Windows command above uses the same curl options, rather than claiming a Windows request was tested.

3. Use a Node stream when you want a scriptable capture. Save this complete GET capture as capture.mjs, then run it with your request URL as its argument. It streams into a partial file and renames it only after the transfer finishes:

   javascript

   import { createWriteStream } from 'node:fs';
   import { rename } from 'node:fs/promises';
   import { Readable } from 'node:stream';
   import { pipeline } from 'node:stream/promises';
    
   const url = process.argv[2];
   if (!url) throw new Error('Pass the GET request URL as the argument');
    
   const response = await fetch(url);
   if (!response.ok || !response.body) {
     throw new Error(`Download failed: HTTP ${response.status}`);
   }
    
   await pipeline(
     Readable.fromWeb(response.body),
     createWriteStream('response.json.part')
   );
   await rename('response.json.part', 'response.json');
   console.log('Saved response.json; validate its content next');

   Node's stream documentation describes the pipeline operation. This writes the response stream rather than collecting the whole body merely to display it. The browser can still need substantial memory for its own parsed object; bypassing the inspector does not change your application data model.

   Both Node streaming and curl saved the fixture in the reproduction. The resulting files had the expected length, matched the fixture's SHA256 hash and parsed as JSON. Their success was checked from the saved contents, not inferred from the status code.

Verify the fix#

A file appearing on disk is the start of verification. For JSON, parse it and check the fields your application expects. For a PDF, archive or image, use the relevant file-format check. Compare a checksum when you have a trusted expected checksum for the same content. A hash with nothing trustworthy to compare against is only an identifier, not proof that the server sent the right file.

For a manageable JSON capture, this Node script reports the stored byte count and checks parsing without printing the whole response:

import { readFile } from 'node:fs/promises';
 
const bytes = await readFile('response.json');
const data = JSON.parse(bytes.toString('utf8'));
console.log({ storedBytes: bytes.length, parsedType: typeof data });

That checks syntax, not your application's schema. Add a check for the required payload field before treating the capture as useful. In a separate control, the fixture server returned HTTP 200 with malformed JSON; Chromium still rejected parsing:

CONTROL HTTP200 invalid-JSON {"status":200,"parsed":false,"error":"Unexpected end of JSON input"}

For compressed responses, do not compare the decoded JSON byte count directly with an encoded transfer length. Content-Encoding describes the representation's compression. Inspect which representation your expected size or checksum describes. The fixture used uncompressed JSON, so its server bytes and saved bytes were directly comparable.

A repeated request is also a new capture, not reconstruction of the discarded original. Time-dependent results, expired URLs or changing server data can make it different. If your application already holds the needed result, retain or export that value before replaying anything; serialising a parsed object produces a new JSON representation, not necessarily identical original response bytes.

Preserve log keeps a history, not a guaranteed body archive#

The Chrome Network reference documents Preserve log as keeping requests across page loads. That does not give the discarded inspection copy back. In the protocol test, a recorder retained the request ID and 200 status while body retrieval failed. With a constrained total capture buffer, the first response was initially retrievable, then became evicted after further responses; its recorded metadata remained present. No Preserve log checkbox was operated in that test.

Enlarging the test buffer also did not restore the body of the already evicted request. A fresh capture was needed. Disabling HTTP cache was tested separately and did not repair the deliberately small inspector buffer. The browser's reuse cache and the inspection body's storage should therefore not be treated as interchangeable fixes.

When isolating a request, avoid mixing it up with another invocation. If your React development effect starts the request twice, the effect setup and cleanup explanation helps identify that sequence. It does not mean Strict Mode caused this eviction. If navigation abandons the component's request, review the request-cancellation pattern before using an old result to diagnose the current screen.

Keep the evidence for each layer separate: the response status, the application's consumed value, the saved file and the inspector's retained copy answer different questions. Capture the body you need, check its contents, and use a clean request history to identify the correct response rather than guessing a universal file-size boundary.

Further reading: SyntaxError: Unexpected end of input with mode: 'no-cors'.