Chrome 152 makes a familiar debugging loop shorter: capture a failing request, resend it, and inspect what actually crossed the wire. Google's August 25, 2026 DevTools release notes describe a broader Resend command and new binary request-payload decoding options.
The useful Dev Tips angle is what you do with that evidence. An intermittent failure becomes actionable when another engineer can reproduce it under stated conditions. This playbook combines the new controls with established Network-panel tools; the experimental sequence below is our recommended workflow, not a claim that Chrome automatically diagnoses your API.
1. Write down the failing interaction first
Start with a concrete sentence: “Opening the invoice drawer after switching accounts returns an error.” Include the account role, route, browser version, and whether this happens on the first attempt or only after earlier activity.
Use a development or staging account with disposable data. Before resending a request, establish whether it creates records, sends messages, or triggers another external effect. A replay is another execution. A failed response alone does not establish that the server made no changes.
This preparation keeps a convenient debugging button from turning a billing investigation into a duplicate transaction investigation.
2. Capture one clean attempt
Open DevTools before reproducing the interaction. In Network, clear earlier traffic and enable Preserve log if the flow crosses page loads. Filter to the relevant endpoint, then perform the failing action once.
Record the original conditions before changing cache or throttling settings. If the bug only appears after normal browsing, beginning with an empty cache may erase the condition you need to understand. A cold-cache run can be a separate experiment later.
Select the request and inspect its status, headers, response, and timing. Follow the Initiator information to the code that started it. For our invoice example, this distinguishes a drawer's data load from an account-switch refresh hitting a similar URL.
Keep the original request available as your baseline. Do not rely on remembering which of several identical-looking rows failed.
3. Resend before reconstructing
In Chrome 152, the former Replay XHR menu item becomes Resend, with support expanded to fetchable requests. Right-click the captured request and use the command after checking that repeating it is appropriate.
Compare the replay with the original: status, response body, relevant headers, and elapsed time. A successful replay is useful evidence, but it does not prove the original caller is broken. Authentication state, backend state, caches, and timing may have changed between attempts.
Write the observation narrowly: “Original returned an error; immediate replay succeeded under the current session.” That is stronger engineering evidence than “the network is flaky,” because it preserves what you actually know.
If replay fails consistently, you now have a smaller starting point than the full sequence of clicks.
4. Inspect the bytes before changing the payload
Chrome 152 adds Base64, Hex, and UTF-8 decoding choices to the request Payload tab for binary and compressed payload inspection. Choose the representation that helps you compare the captured data with the endpoint's expected format.
Readable text is convenient; hexadecimal can make byte-level differences easier to spot. Neither display mode establishes that a payload satisfies the application's schema. Treat decoding as inspection, then verify the expected serialization with the code that constructs the request.
For a JSON endpoint, compare missing fields, explicit nulls, and unexpected values. For binary uploads, record content type and the observed payload representation. Avoid “fixing” data simply because one display looks unfamiliar.
5. Change one variable per experiment
When you need an editable request, Network's copy options include Copy as fetch and Copy as cURL. Use a local, controlled environment and inspect copied credentials before saving or sharing the result.
Keep method, body, and session conditions unchanged for the first reproduction. Then vary one suspected cause: an account identifier, a missing field, or an ordering dependency. Changing everything at once may produce a passing request without explaining why.
Maintain a short experiment log:
- Baseline: exact interaction and observed failure.
- Replay: same request under the current session, with its result.
- Variation: one deliberate change and its result.
- Confirmation: repeat the original interaction after the proposed fix.
The last item matters. A hand-edited request can validate a hypothesis while the application still generates the wrong request.
6. Hand off a small, reviewed evidence package
Export the relevant requests as a sanitized HAR when the receiving engineer needs the capture. Chrome's sanitized export excludes sensitive headers such as Cookie and Authorization. Still review URLs, request bodies, and response bodies yourself; header filtering is not a guarantee that application data is safe to share.
Attach the reproduction sentence, browser version, experiment log, and expected behavior. Include only the requests necessary to explain the failure.
Your stopping condition is practical: another engineer can reproduce the problem, identify the changed variable, and verify the fix through the original UI interaction. Chrome 152 reduces the effort of collecting that evidence. The discipline comes from keeping each experiment small enough to interpret.