Chrome DevTools extension HAR evidence is useful when a bug report needs more than a screenshot. A failed checkout, missing search result, or intermittent API error often depends on request timing, status codes, redirect chains, and response snippets. A QA engineer can capture that evidence manually from DevTools, but a small DevTools extension panel can make the workflow more repeatable.

This tutorial shows a practical approach: build a Chrome DevTools extension panel that reads HAR-style network data, lets the tester add notes, and exports a compact JSON file for the bug report. The goal is not to replace a full proxy, observability platform, or performance tool. The goal is to give QA teams a focused evidence package that developers can use to reproduce and debug faster.

What This Workflow Can and Cannot Capture

Chrome’s DevTools extension APIs let an extension add panels inside DevTools for the inspected page. The Network API exposes request information in HAR format through chrome.devtools.network.getHAR(), and individual request objects can expose content through getContent(). That makes this workflow useful for API failures, slow requests, failed static assets, redirects, and request metadata.

There are important limits. DevTools must be open for the inspected page. Requests made before DevTools opens may not be available. Request content is not included in the HAR object by default. Sensitive data can appear in URLs, headers, cookies, request bodies, or responses, so the export must be reviewed before sharing. Treat the extension as a QA evidence helper, not as invisible background packet capture.

Chrome DevTools Extension HAR Evidence Setup

Create a small extension folder with a manifest, a DevTools entry page, and a panel page. Keep the permissions narrow. For this basic tutorial, the panel reads from DevTools APIs and saves local notes with extension storage.

Starter Snippet

Use this minimal structure as a starting point:

devtools-har-evidence/
  manifest.json
  devtools.html
  devtools.js
  panel.html
  panel.js

manifest.json

{
  "manifest_version": 3,
  "name": "QA HAR Evidence Panel",
  "version": "0.1.0",
  "description": "Exports HAR-style DevTools network evidence with tester notes.",
  "devtools_page": "devtools.html",
  "permissions": ["storage"]
}

devtools.html

<script src="devtools.js"></script>

devtools.js

chrome.devtools.panels.create(
  "QA Evidence",
  "",
  "panel.html"
);

panel.html

<main>
  <h1>QA Evidence</h1>
  <textarea id="notes" placeholder="Tester notes, expected result, actual result"></textarea>
  <button id="export">Export evidence</button>
  <pre id="preview"></pre>
  <script src="panel.js"></script>
</main>

Export HAR Data with Tester Notes

The panel can call chrome.devtools.network.getHAR(), filter the entries, and build a smaller evidence object. QA teams usually do not need every successful image or analytics request in a bug report. Start with failed requests, slow requests, and requests related to the feature under test.

const notesBox = document.querySelector("#notes");
const preview = document.querySelector("#preview");
const exportButton = document.querySelector("#export");

async function saveNotes() {
  await chrome.storage.local.set({ qaEvidenceNotes: notesBox.value });
}

chrome.storage.local.get("qaEvidenceNotes", (data) => {
  notesBox.value = data.qaEvidenceNotes || "";
});

notesBox.addEventListener("input", saveNotes);

exportButton.addEventListener("click", () => {
  chrome.devtools.network.getHAR((harLog) => {
    const importantEntries = harLog.entries
      .filter((entry) => {
        const status = entry.response?.status || 0;
        const time = entry.time || 0;
        return status >= 400 || time > 1000;
      })
      .map((entry) => ({
        method: entry.request.method,
        url: entry.request.url,
        status: entry.response.status,
        statusText: entry.response.statusText,
        timeMs: Math.round(entry.time || 0),
        startedDateTime: entry.startedDateTime,
        mimeType: entry.response.content?.mimeType || "",
        requestHeaders: entry.request.headers,
        responseHeaders: entry.response.headers
      }));

    const evidence = {
      inspectedTabId: chrome.devtools.inspectedWindow.tabId,
      capturedAt: new Date().toISOString(),
      testerNotes: notesBox.value,
      summary: {
        totalRequests: harLog.entries.length,
        includedRequests: importantEntries.length
      },
      network: importantEntries
    };

    preview.textContent = JSON.stringify(evidence, null, 2);
  });
});

This example previews the evidence in the panel. In a production version, add a download button that creates a JSON file or copies the evidence to the clipboard. Keep the first version simple so testers can validate the data before the extension becomes part of a team workflow.

Step-by-Step QA Workflow

1. Open DevTools before reproducing the bug. This matters because the Network API is tied to DevTools. If the failure happens during initial page load, open DevTools first, enable the Network tab, and then reload the page.

2. Reproduce the issue once cleanly. Avoid mixing several test attempts in the same capture. If the first attempt is noisy, clear the Network log and reproduce again.

3. Add tester notes in the panel. Include environment, test data, user role, expected result, actual result, and any feature flag or build number. The notes are as important as the request list because they explain why the network event matters.

4. Export the evidence. Review the generated JSON before attaching it. Remove tokens, cookies, emails, payment-like data, and internal URLs that should not leave the team.

5. Attach the file to the bug report. Add a short human summary first, then attach the evidence file as supporting detail. Developers should be able to scan the report without opening the JSON immediately.

What to Include in the Bug Report

A strong bug report should combine the DevTools extension export with normal QA context. Include reproduction steps, expected result, actual result, browser version, account or role, test environment, and the exact timestamp. In the exported evidence, keep the failed request URL, method, status code, timing, and relevant headers. If response content is needed, capture only the smallest safe snippet and make sure it is allowed by your team’s data policy.

Common Mistakes

Opening DevTools too late. If DevTools is opened after the failure, the important request may be missing. Reproduce with DevTools already open.

Attaching raw data without review. HAR-style exports can contain sensitive information. Build a review habit into the workflow.

Exporting every request. A huge JSON file is harder to use. Filter by failures, slowness, or feature-specific endpoints.

Claiming full background capture. A DevTools extension panel is an inspected-page debugging tool. It is not the same as a proxy or endpoint telemetry system.

Screenshot Checklist

  • Extension loaded in chrome://extensions with Developer mode enabled.
  • DevTools open before reproducing the bug.
  • Network tab showing the failed or slow request.
  • QA Evidence panel showing tester notes and the generated preview.
  • Bug report with reproduction steps plus the attached evidence file.

Best Practices for QA Teams

Keep the extension local or internal until the workflow is reviewed. Document which fields are safe to attach. Add a redaction checklist for cookies, tokens, authorization headers, emails, phone numbers, and customer data. If your team uses Jira, Azure DevOps, GitHub Issues, or another tracker, standardize the bug report template so the HAR-style export supports the report instead of replacing it.

Also keep the evidence format stable. Developers should not need to relearn the JSON shape every sprint. If the extension changes, update the sample bug report and screenshot checklist at the same time.

FAQ

Is Chrome DevTools extension HAR evidence the same as a full HAR export?

No. The DevTools Network API exposes HAR-style request data, but request content is not included by default and the available data depends on DevTools being open for the inspected page.

Can this capture requests before DevTools opens?

No reliable QA workflow should assume that. Open DevTools before reproducing the issue, then reload or repeat the action that triggers the request.

Should QA attach the full export to every bug?

No. Attach it when network behavior helps explain the defect. For visual-only bugs, a screenshot and clear reproduction steps may be enough.

Can this replace backend logs?

No. It complements logs by showing what the browser observed. Backend logs, API traces, and monitoring data are still needed for server-side root cause analysis.

Conclusion

Chrome DevTools extension HAR evidence gives QA engineers a repeatable way to package network failures with useful context. The safest version is intentionally modest: open DevTools before reproducing, capture filtered HAR-style request data, add tester notes, review for sensitive information, and attach the result to a clear bug report. That workflow helps developers move from “cannot reproduce” to targeted debugging faster.

References