How to Create and Share a HAR File Safely for Web Debugging

Overview

When a website fails, a screenshot often shows the visible symptom but not the request that caused it. A server log may show what reached the backend but not what the browser sent, blocked, cached, or received. A HAR file helps connect those details by preserving a structured record of browser network requests and responses during a troubleshooting session.

HAR stands for HTTP Archive. The file normally uses the .har extension and contains entries such as request URLs, methods, status codes, timing information, headers, cookies, redirects, and sometimes response content. That detail makes a HAR useful for diagnosing failed API calls, authentication loops, CORS problems, slow page elements, unexpected redirects, and assets that do not load.

It also makes a HAR potentially sensitive. Depending on the browser and the activity captured, it may contain session cookies, authorization values, account identifiers, search terms, form data, internal hostnames, and response content. Treat it like a diagnostic export, not like an ordinary screenshot. Before sending it, review the file and remove or replace anything the recipient does not need.

For related preparation, see the guide to redacting API keys and secrets from logs. If the final capture is large, a compressed archive may help, but compression does not provide privacy by itself.

What to track

Record the right browser session

Before opening developer tools, write down the problem you are trying to reproduce. Include the page or API endpoint, the approximate time, the browser and operating system, the account or role being tested, and the exact action that fails. Avoid including passwords or full personal data in the notes.

Open the browser’s developer tools and select the Network panel. Keep the panel open, enable the option that preserves the network log if the issue involves navigation or redirects, and clear existing entries. Reproduce the problem once using the smallest realistic sequence of actions. If possible, avoid unrelated tabs and activity so the capture contains fewer requests.

Use the Network panel’s filter controls to understand what happened before exporting. Look for requests with client or server error status codes, failed requests, long duration, repeated redirects, blocked resources, and preflight requests. A useful HAR is not necessarily the largest one; it is the one that captures the failure and enough surrounding context to explain it.

Export a HAR file in Chrome

1. Open the page where the problem occurs.
2. Open Developer Tools from the browser menu or with the browser’s developer-tools keyboard shortcut.
3. Select Network and clear the existing request list.
4. Reproduce the issue while recording the relevant requests.
5. In the Network request list, open the context menu and choose the HAR export option. Chrome may offer an export that includes sensitive data or a sanitized option, depending on the version and context.
6. Save the file with a descriptive name, such as checkout-timeout-2026-10-30.har, without placing secrets in the filename.

Menu wording can change between browser releases. If the export command is not visible, look for a download or save option in the Network panel’s toolbar or context menu. Export only after reproducing the issue, rather than sending a capture of an unrelated session.

Export a HAR file in Firefox

1. Open Developer Tools and choose the Network panel.
2. Clear previous entries and, when appropriate, enable persistence so navigation does not remove the requests you need.
3. Repeat the action that produces the error.
4. Use the Network panel’s save or export control, or its context menu, to save the captured requests as a HAR file.
5. Confirm the file opens as plain structured data before sharing it.

Firefox labels and locations can vary by release and operating system. If you cannot find the export command, inspect the Network panel toolbar and right-click menu rather than relying on an exact menu path.

Export a HAR file in Edge

1. Open Developer Tools and select Network.
2. Clear the list, then reproduce the issue once.
3. Use the Network panel’s export or save command to download the HAR file. Edge may present options related to including sensitive information.
4. Save the capture locally and inspect it before uploading or attaching it to a ticket.

Because Edge and Chrome share similar developer-tool conventions, their controls may look alike, but the exact labels can change. Check the current Network panel rather than assuming that a previously documented path is unchanged.

Use a privacy checklist before sharing

• Cookies: Search the file for cookie names and values. Remove session cookies and persistent identifiers unless the recipient has a documented reason to inspect them.
• Authorization headers: Remove Authorization, bearer tokens, API keys, signed URLs, and similar credentials. A token that looks expired may still expose account access or sensitive metadata.
• Query parameters: Inspect URLs for email addresses, customer IDs, search terms, reset tokens, invitation codes, and other values. Replace unnecessary values while preserving the structure needed for debugging.
• Request and response bodies: Check form submissions, JSON payloads, HTML, and response previews for names, addresses, payment details, health information, internal data, or uploaded content.
• Hostnames and paths: Decide whether internal domains, project names, or infrastructure details are needed. If not, replace them consistently rather than deleting only one occurrence.
• Personal notes and filenames: Use a neutral filename and remove account names or customer information from accompanying descriptions.

Do not edit a HAR casually if the edit could change the evidence. Keep an untouched copy in an access-controlled location, make a redacted working copy, and record what was removed. If the capture includes an active credential, do not rely only on redaction: revoke or rotate the credential according to your team’s incident procedure. For broader file-cleaning guidance, review how to remove file metadata before sharing.

Cadence and checkpoints

A HAR is usually created for a specific incident, but teams benefit from a repeatable capture process. Add a short checkpoint to your troubleshooting workflow whenever a new browser version, application release, authentication flow, or support process changes.

Before recording, confirm that the test account is appropriate and that production data is not required. During recording, capture one clean reproduction and note the timestamp, timezone, browser version, page, expected result, actual result, and steps taken. After recording, verify that the file contains the failed request and that the privacy review is complete.

For recurring support work, review the checklist monthly or quarterly. Ask whether browser menu paths still match the team’s instructions, whether the application now sends new sensitive fields, whether support recipients still need the same request details, and whether the storage or transfer method remains approved. A team can also maintain a small redaction test file to confirm that its review process catches cookies, authorization headers, query values, and personal data.

When sending the file, use an access-controlled transfer method with an expiration where practical. Share the access link separately from the incident description when the transfer system supports that approach. Avoid posting a raw HAR in a public issue, open chat room, or repository. If the file is too large, compress it only after redaction; see the comparison of ZIP, 7z, TAR, and GZIP for format considerations.

How to interpret changes

Compare captures by looking at the request sequence, not only the final error. A request that returns a client error may indicate invalid input or authorization. A server error may require backend investigation. Repeated redirects can point to a session or identity problem, while a blocked preflight request may direct attention to CORS configuration. Long timing values can help distinguish connection, server-processing, and resource-loading issues, but they should be interpreted alongside server and application logs.

A screenshot is usually better when the issue is purely visual, such as a layout defect or a visible validation message, and the screenshot contains no unnecessary personal data. Server logs are better for backend exceptions, database failures, queue processing, and events that occur without a browser. A HAR is most useful when the boundary between browser and server is part of the question: what was requested, which headers were sent, what response arrived, and how the browser handled it.

Do not treat a HAR as proof of the entire system’s behavior. It represents one browser session, one account context, one network environment, and one moment. A missing request may mean the action was not reproduced, the request was served from cache, or the relevant event occurred outside the browser. Use it with application logs, reproducible steps, and, where appropriate, a sanitized screenshot.

When to revisit

Revisit this process whenever Chrome, Firefox, or Edge changes its developer-tools export controls; when your application adds a new login, payment, upload, or personal-data flow; or when a team changes where diagnostic files are stored and shared. Also revisit it after any incident in which a capture contained more sensitive information than expected.

Before your next bug report, use this practical sequence:

1. Define the failure and record the minimum reproduction steps.
2. Capture one focused Network session in the browser that shows the issue.
3. Export the HAR using the current browser control.
4. Search the file for cookies, authorization values, tokens, query parameters, personal data, and internal details.
5. Create a redacted copy, document the redactions, and rotate any exposed credential.
6. Send it through an access-controlled transfer method with a clear expiry or deletion plan.
7. Pair the HAR with the browser version, timestamp, expected result, actual result, and relevant server-log reference.

This routine keeps a HAR useful for debugging without turning a troubleshooting attachment into an avoidable security exposure. For transfer-specific choices, compare SFTP, FTPS, and HTTPS file transfer, and consider a checksum when the recipient needs to verify that the capture was not altered in transit.