Summary
Start with a narrow debugging question. Capture only the relevant session, review the exported file, preserve the useful context, and confirm where it will be sent. A sanitized export still needs application-specific review.
A support engineer asks for a HAR file. Before attaching it, decide what the recipient needs to understand—and what information should stay with your team.
HAR files contain browser network activity. Depending on the capture, they can include request and response headers, body content, and timing information. Cloudflare’s support documentation warns that a HAR can contain passwords and payment information. Treat the exported file as a document that needs review. 1
This guide combines documented browser behavior with OrbitalWake’s recommended workflow. It does not evaluate a particular sanitizer or certify a file as safe to share.
What Chrome’s sanitized export does
Chrome DevTools documents a sanitized HAR export that excludes sensitive information such as the Cookie, Set-Cookie, and Authorization headers. The Network panel also supports an export with sensitive data when that option is enabled. 2
That documented behavior is a useful starting point. It does not establish that every value relevant to your application has been removed. Google Cloud’s capture guidance separately warns about information submitted through forms and advises redacting sensitive information before sharing. 3
1. Define the debugging question
Write down the failure you want the recipient to investigate. For example: “The invitation request returns an error after the user clicks Send.”
Identify the affected action, approximate time, expected result, and actual result. Ask whether a short description and selected response details would answer the question before collecting a larger capture.
Where you can reproduce the issue with synthetic data in a test account, use that route. Record any differences from the original environment that could affect the result.
2. Capture a short, relevant session
In Chrome’s Network panel, make sure network recording is on. If navigation is part of the failure, enable Preserve log before reproducing it; this retains requests across page loads. Clear previous requests, reproduce the issue, and stop recording once you have captured the relevant sequence. 2
Keep a brief note of your reproduction steps and browser version. Avoid unrelated browsing during capture. If you need another attempt, check whether you are collecting a clean reproduction or mixing several attempts together.
3. Review the actual exported file
Choose the sanitized export, then inspect the file you intend to send. Before using a HAR viewer or sanitizer, check whether it processes the file on your device or sends it to another service. Only send the capture to a destination authorized for the data it contains.
Our recommended review covers:
- URLs and query values.
- Request and response headers, including application-specific headers.
- Submitted form fields and request bodies.
- Response content.
- Customer names, identifiers, and business information that the recipient does not need.
OWASP’s logging guidance identifies access tokens, session identifiers, passwords, encryption keys, and sensitive personal or commercial information as data that generally should not appear directly in logs. Use those categories to inform your review, while accounting for your own application’s fields. 4
Do not assume a search for the word “password” finds every sensitive value. A field’s meaning may be specific to your product.
4. Preserve the explanation
Prepare a separate shareable copy. Keep the original and edited copies in an approved location with access limited to authorized people. When replacing a value, use an obvious placeholder and describe the change in an accompanying note.
For example, if two requests refer to the same customer, a consistent placeholder such as customer-example-01 can preserve that relationship. Keep the minimum sequence, status information, and timing needed to explain the failure.
These are editorial recommendations, not proof of anonymization. Review the edited copy with a tool approved for the data it contains. Chrome DevTools supports importing a saved HAR through the Network panel’s Import HAR control. 2 Check that the edited file still opens and that your changes have not obscured the issue. If they have, ask which additional detail is necessary.
5. Check the recipient and destination
Share only information you are authorized to disclose. If you are unsure whether a field can be shared, ask the data owner or your security team before attaching the file.
Use the intended vendor’s support channel and confirm which case should receive the attachment. Google Cloud, for example, prefers sharing through the support case when feasible and provides a separate permission-based process for other file sharing. Follow the relevant vendor’s instructions rather than assuming every support system works identically. 5
Before sending, read the attachment once more alongside your reproduction notes. Make the scope of the capture and your edits clear. Agree on retention or deletion expectations when the material warrants it.
A useful debugging bundle gives the recipient enough context to investigate a specific problem. Its size and detail should follow that purpose.
Sources & scope
This guide is based on public documentation checked on 25 Oct 2026. No live application or sanitizer test was performed for this article.
- Cloudflare: Gathering information for troubleshooting sites
- Chrome DevTools: Network features reference
- Google Cloud: Capture browser trace information
- OWASP: Logging Cheat Sheet
- Google Cloud: Privacy best practices for Customer Care
Publishing details & corrections
Prepared with AI assistance and reviewed against the cited public documentation. The numbered workflow is editorial guidance.
No material corrections recorded for this version.