Chrome Can Now Resend Any Request. What That Does and Does Not Tell You

Chrome 152’s DevTools notes went up on 25 August 2026, and one line in them matters more than its size suggests. The Network panel’s old Replay XHR menu item is now simply Resend, and Chrome’s own description of the change is exact:

It now supports all fetchable network requests, converting standard requests to fetch() calls while preserving full replay fidelity alongside XHR.

Replay XHR had been sitting in that menu for years, useful only for the specific kind of request it named. Any other failing request - a form post, a document fetch, an upload - had to be reconstructed by hand as a curl command or in a client. Now you right-click it and send it again.

The same release gives the Payload tab decoding options - Base64, Hex and UTF-8 - for binary and compressed request payloads, mirroring what the Response tab already offered. Anybody who has looked at a failing file upload or a compressed body and seen nothing usable now has three ways to read it.

Why this matters when the request was not yours

Both changes land on the same activity: working out what happened from a request you did not make.

That is most bug reports. Somebody hit a failure, the failing request is in front of you, and the question is whether you can get from it to a cause. Being able to resend it in one click, and to read a payload that used to be opaque, removes two of the errands in that job.

The part worth being careful about

A resend is not the request that failed. It is a new request that looks like it.

It runs from your browser, with your cookies, your session, your extensions and your IP address, at a time that is not the time it originally failed. That is four differences before you have changed anything, and each of them can flip the outcome:

What a resend answers

Does this shape of request fail for me, from here, right now?

What the report has to answer

Why did this request fail for that person, on their session, at that moment?

A 403 that resends as a 200 usually means the difference was in the session rather than the request. A 500 that resends as a 500 is a gift, because you have a reproduction you control. A timeout that resends instantly is telling you the state that caused it has passed - which is the 504 case exactly.

None of that makes Resend less useful. It makes it a first question rather than an answer, and knowing which of the two you are holding is the whole skill.

What the report has to carry for any of it to work

You cannot resend a request you do not have. What makes this new capability reachable at all is whether the failing request survived the trip from the person who saw it to the person fixing it, with its method, its URL, its headers and its body intact.

That is what a network log in a bug report is for, and it is why HAR files exist as a format at all.

One honest limit on our own side: we mask credential headers and values by default, and on a domain that has not asked for anything else we mask them everywhere. So a request replayed out of a report we captured will usually need its authorization supplied by the person doing the replaying. That is the trade we chose - a report is a link somebody can open, so anything captured is effectively shared - and it is worth knowing before you wonder why the resend came back unauthorized.

The rest of the release, briefly

Three other things in the same notes are worth a developer’s minute.

Copy as preload element. Right-click a request and get a <link rel="preload"> tag ready to paste, which turns a performance observation into an edit without the intermediate step of looking up the syntax.

Structured table exporting in the Console, so a table you logged can leave the console as data rather than as a screenshot of data.

Switching between the DOM tree and the accessibility tree from the context menu in Elements, with “scroll into view” for accessibility nodes. Small, and it lowers the cost of checking the thing most teams check least.

What to take from it

A browser release note is not usually worth reading twice, and this one is, for a reason that has nothing to do with the features being large: it improves the tooling around evidence somebody else collected. That is a category most debugging tools have historically been poor at, because they assume the person holding the browser is the person who found the bug.

They are usually not the same person. Anything that shortens the distance between the two is worth more than its release note suggests.

Chrome’s own notes are the place to read the full list: What’s new in DevTools (Chrome 152).