Building in Public? A Sanitized HAR File Still Needs a Review

To share a HAR file safely, start by deciding whether a public discussion needs the file at all. Prefer a small reproduction made with invented data, export a sanitized HAR when a diagnostic file is actually necessary, and review the exported contents before sharing. “Sanitized” describes a filtering step; it does not tell you that every remaining field is suitable for publication.

When you build in public, a useful debugging update can explain what you observed without exposing the request log behind it. Separate the public learning from the private diagnostic artifact. That gives other developers something concrete to discuss while keeping the amount of shared information tied to the actual question.

Know what the export promises

Chrome DevTools’ Network reference describes HAR as a JSON format for logged network requests. Its default sanitized export excludes the Cookie, Set-Cookie and Authorization headers. DevTools also offers sensitive-data export options. This guide uses the sanitized path; there is no reason to enable sensitive export just to make a public build update.

Those documented exclusions are useful, but they are a specific claim about headers. Do not extend them into a claim that an export contains no private information. Review other visible fields, including URLs, parameters, request content and responses. The information a particular capture contains depends on what the browser did during that capture.

The practical distinction is between a tool’s removal rule and your sharing decision. The first can be automatic. The second needs the context of the application, the intended recipient and the purpose of the discussion. If you cannot confidently inspect the file, ask for an approved support route or supply a smaller explanation instead.

Begin with the question the public post needs to answer

Consider a fictional developer building a form preview tool. A preview panel refreshes twice after a save. They want to show peers the sequence and ask whether their explanation of the behavior is clear. A production-session HAR would include far more activity than that question requires.

For a public post, the developer can describe the test conditions, the duplicate refresh they observed and the fact that the cause remains unconfirmed. A short conceptual timeline may be enough: save accepted, preview requested, second preview requested. Label it as a simplified account rather than an exact trace or a proven diagnosis.

If another developer needs more evidence, clarify which observation would help. They may need the request order or a status code, rather than all headers and bodies. A narrow request makes it easier to choose an appropriate artifact. It also prevents “send the HAR” from becoming the default answer to every debugging conversation.

Reproduce with a separate test context

Use a test account and invented content where you are authorized to do so. Keep the example small enough that you can explain every relevant input. For the fictional preview tool, a document called “Sample page” with a short dummy paragraph is more appropriate than a real customer’s unpublished document.

Begin recording as close to the relevant action as practical. Clear unrelated earlier requests from the Network panel before reproducing the issue, then stop once the needed behavior has appeared. This reduces unrelated material; it does not prove the result is safe. Review is still necessary even when the session was intended only for testing.

Record the conditions separately: browser version, product build if available, action taken and expected result. Do not add personal account details simply to make the report feel complete. If you cannot reproduce the problem without real private information, move the investigation to the service’s established private support process instead of forcing a public example.

Inspect the file you exported

Review the exported artifact rather than assuming it matches the rows you remember looking at. Check which hosts and requests are present. Look for unrelated services and activity outside the test. A recording can include requests you did not intend to discuss, even if your public screenshot shows only one selected row.

Read the remaining URL paths and query parameters. Then inspect any request and response content that the file contains, along with custom headers and other metadata. Look for information that identifies a person, an account or private work. Do not rely on a search for one familiar word as a complete review.

In this fictional case, the developer might discover a document title embedded in a path even though the standard sensitive headers were excluded. That is a hypothetical risk illustration, not a claim about a particular product. Recreating the capture with dummy content is preferable to casually editing a complex file and assuming every private value has been removed.

Keep the public artifact smaller than the investigation

The public update can say: “In this test, one save was followed by two preview requests. I have reproduced the sequence using dummy content. I have not yet established whether the second request causes the visible flicker.” This separates the observed request sequence from a causal claim that still needs work.

A useful accompanying image could be a carefully reviewed crop with abstract test values, or a simple diagram rebuilt from the relevant sequence. Explain which parts are simplified. Do not present a reconstructed diagram as an untouched capture. Readers should know whether they are looking at raw evidence or your explanation of it.

Avoid posting a full diagnostic archive as proof of being transparent. The amount of information disclosed is not a measure of how honestly you are building. A clear account of the question, the conditions and the remaining uncertainty can be more useful to a peer than a file they must inspect from scratch.

Use a private handoff when the file is needed

If a maintainer or support team actually needs a HAR, use the channel they specify and confirm what they need before sending it. Check the recipient and the artifact together. A file suitable for a particular private investigation is not automatically suitable for a public issue tracker, community thread or newsletter attachment.

Describe how the capture was made and which sanitization option you used. Do not claim it is risk-free. Also state whether it uses dummy data and whether the observed behavior matches the original problem. A clean synthetic capture may be safer to review, but a failure to reproduce the original symptom is a limitation worth reporting.

If you discover sensitive information after sharing, use the service’s established incident or support process. Removing a public attachment may limit further access, but it cannot establish that no one already copied it. Do not improvise a public investigation by asking others to download the file and tell you what they find.

Ask peers to review the explanation first

A founder community is useful for checking whether your public debugging note is understandable. Buildside’s about page describes sharing product progress and offering specific observations; I build Buildside. That context supports a request such as “Can you distinguish the observation from my current theory?” It does not require uploading a private diagnostic file to the community.

Give the reviewer the minimal public note and ask what conclusion it supports. If they infer that the cause is confirmed when you have only seen a repeated request, revise the wording. This is a check on the explanation, separate from a technical diagnosis. A well-written post can still contain an unproven theory.

Before publishing, make a final comparison between the question and the artifact. Does every included detail help someone assess that question? Can you explain the test without the file? Has the exact exported content been reviewed? A sanitized HAR can be a useful diagnostic tool, but careful public building starts with choosing what evidence needs to leave the debugging session.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

Chrome DevTools Network reference: HAR exports

About Buildside and its founder