Chrome dev tools fails to show response even the content returned has header Content-Type:text/html; charset=UTF-8

Question

Why does my chrome developer tools show "Failed to show response data" in response when the content returned is of type text/html?

What is the alternative to see the returned response in developer tools?

Solution 1

I think this only happens when you have 'Preserve log' checked and you are trying to view the response data of a previous request after you have navigated away.

For example, I viewed the Response to loading this Stack Overflow question. You can see it.

The second time, I reloaded this page but didn't look at the Headers or Response. I navigated to a different website. Now when I look at the response, it shows 'Failed to load response data'.

This is a known issue, that's been around for a while, and debated a lot.

Solution 2

For the ones who are getting the error while requesting JSON data:

If your are requesting JSON data, the JSON might be too large and that what cause the error to happen.

My solution is to copy the request link to new tab (get request from browser) copy the data to JSON viewer online where you have auto parsing and work on it there.

Solution 3

As described by Gideon, this is a known issue with Chrome that has been open for more than 5 years with no apparent interest in fixing it.

Unfortunately, in my case, the window.onunload = function() { debugger; } workaround didn't work either. So far the best workaround I've found is to use Firefox, which does display response data even after a navigation. The Firefox devtools also have a lot of nice features missing in Chrome, such as syntax highlighting the response data if it is html and automatically parsing it if it is JSON.

Solution 4

As described by Gideon, this is a known issue.
For use window.onunload = function() { debugger; } instead.
But you can add a breakpoint in Source tab, then can solve your problem. like this:

Solution 5

If you make an AJAX request with fetch, the response isn't shown unless it's read with .text(), .json(), etc.

If you just do:

 r = fetch("/some-path");

the response won't be shown in dev tools.
It shows up after you run:

r.then(r => r.text())

View more solutions

Comments

[For the Name]

I have found that Microsoft Edge Dev (based on Chromium) does not give me this error.

[Rajendra kumar Vankadari]

Did you try checking in Firefox ?

[Alkanshel]

Not being able to see response data almost entirely kills the point of "preserve log"!

[Shane N]

Your window.onunload workaround worked great, thank you!

[O. R. Mapper]

No, in Chrome 61, it can definitely also happen if "Preserve log" is not checked, and without leaving the page.

[Gideon Pyzer]

The response data can be large, and with preserve log checked indefinitely, would build up significantly hindering DevTool performance. To discard the response data upon navigation was probably done by design. If you have some suggestions, comment on the thread linked above.

[cronfy]

It does not work if request you want to inspect gives immediate redirect with javascript. There is just no time to open console and add onunload handler. But Firefox helps in such situations.

[ievgen]

As alternative you may try chrome.google.com/webstore/detail/network-record/… extension

[phil294]

not really a solution though. I work with authentication and such. Defies the purpose of the dev tools. Somebody should probably create some bugreport somewhere. Correct answer here though

[Willem Hengeveld]

Is this limit configurable in any way?

[mozzbozz]

Wow, great thing. Needing to debug an error which only occurs to Chrome, not Firefox. So also no option for me. Seriously, why does everyone say the Chrome web tools are so much better than Firefox's? Seems like they didn't try Firefox for years.

[Antimony]

Chrome also doesn't have Firefox's convenient "edit and resend" request option.

[Mihail Malostanidis]

What's the advantage of the Source tab over window.onunload = function() { debugger; }?

[boatcoder]

In my case it happened at 23MB which is a stupid large JSON response.... I opened an issue to have the error message made more descriptive.

[Onza]

Still experiencing this issue with chrome 73.0, the onunload fix doesn't work for me for some reason.

[Parijat Kalia]

you don't need to write the code for the debugger, and you can debug on higher environments where you maybe jumping between pages and don't preserve the same window

[mehov]

window.onunload = function() { debugger; } didn't work for me, this did. thanks!

[mehov]

Same here: the unload fix pasted into the console did not work in my case, but @Nolan's advice with the Sources tab did (it also seemed more elegant).

[Vincent-cm]

@GideonPyzer sorry, can the workaround debug live code?

[nmirceac]

chrome is still broken for not showing the response (in any shape whatsoever) - FF worked for me

[nmirceac]

Yes... Also used FF to get the thing done... Worked as expected. We're living treacherous times!

[Ivan Hušnjak]

@Antimony chrome did had "Resend" option for quite a while, but in one of the last releases they have removed even that... Luckily one can do quick fetch(...copied link...) in console, and observe response in network tab

[Andrei Diaconescu]

the error happens also when i do not have "Preserve log" checked

[thephpdev]

Still getting this even now. For crying out loud I'd rather them fix what they already have rather than introduce pointless features like eager evaluation in the console and neglect the quality of their fundamental developer tools.

[Kevin S.]

Your solution seems promising, but it clearly skips some steps for someone with less knowledge than you do about chrome. What is one supposed to do with "window.onunload = function() { debugger; }"?

[van_folmert]

window.onunload = function() { debugger; } doesn't work anymore

[Lee Gunn]

I'm seeing the issue for 6MB JSON :(

[Amir]

You are right! But this is exactly why I need the reponse to understand why my request is failing. Everything works fine with curl, but chrome still fails with "Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource"

[miki noidea]

Also hitting this on JSON response arond 6mb uncompressed.

[David Mårtensson]

An exact replica is no use if the server state supplying the response has changed. So for me, that have to wait around 40 minutes for an event to happen, and that event triggers a new page, this completely breaks the whole use. It should be an option that could be toggled. UInfortunatly there is no vote or comment option for common visitors to the issue listed in a previous comment unless you are part of their team :/

[David Mårtensson]

You cannot comment on the thread linked unless you have editor permission, I tried. And adding debugger to the source is a no go as this is production level code, debug code is not an option. And Firefox apperently can preserve it fine, even a few hours of log, so whats chromes problem? Yes it might eat memory, but only if you open devtools, and then you are probably more interested in data than in performance. And if its still a problem, add a toggle.

[TommyAutoMagically]

Unbelievable. 8 year bug?! At the VERY least, the window should show a warning about the missing data.

[mgraham]

I got the error with only 227KB of json - scaled it back and it works ok for 25KB, so definitely a size issue

[TommyAutoMagically]

GAAAAAH This bit me AGAIN. A few hours down the drain.

[Alexey Grinko]

This beforeunload handler didn't work for me, but its slightly modified version worked: window.addEventListener('beforeunload', function(e) { e.returnValue = 'Are you sure?'; return e.returnValue; }); Just click "Cancel" in the confirmation modal to prevent page reload, and go to the Network tab to see the response body - it is there.

[xr280xr]

I got this when the site just wasn't running (local development out of Visual Studio)

[Kos]

Is there any bug opened about this behaviour of dev tools? This is ridiculous

[Bhargav Nanekalva]

Isn't that super inconvenient to switch between browser, ide and postman?

[user1439838]

I advice everybody who face this issue to star it here: bugs.chromium.org/p/chromium/issues/detail?id=141129 It is still not fixed because it has to little stars :(

[Tim]

@Kos agree, still not fixed. Just spent 1:30 hour figuring out why I didn't get a response.

[Stefan]

Just wasted an hour on this, looks like Chrome is still not fixed. I finally checked with Postman because I tought I was going crazy and there was my content in all its glory.

[Isaac Lyman]

I was able to get at the data in a roundabout way by right clicking the request, choosing Copy > PowerShell request, storing the result as $Response in PowerShell, then following the example here to stream it to a file. (May have to decode if you're requesting a compressed response.)

[developius]

Same here. I use Brave but was reproducible on Chrome too (obviously). Bug not present in Safari. Just lost two hours on this, assumed there was a problem with the server.

[mikiqex]

Thanks a lot, I wouldn't guess such behavior in a million years. Btw. I'm using Edge Dev 96.

[Alex]

As much as I respect highly skilled developers of Chrome, I do think they are on drugs or have some other mental issues. Having a Dev Tools feature that IS able to store request history but not request details is Very strange, not fixing this bug/feature it 9 years is outright weird.

[Sathiamoorthy]

@BhargavNanekalva, Agreed but it helps sometimes.

[sammy]

@user1439838 how to incr stars?

[Revadike]

@user1439838 how to star it?

[mani bharataraju]

This answer should be accepted. Tried so many things and to finally find out this. Duh!

[gre_gor]

@manibharataraju The question itself is quite vague. There are many reasons and solutions for this problem and the accepted one is the one that helped the asker.

[gre_gor]

@manibharataraju Also now I can't reproduce this problem. The content is shown without reading it first. It seems this "bug" was fixed.