Secure HAR Viewer, Analyzer & Secret Sanitizer
Inspect HAR files locally, find slow requests, compare traces, and redact cookies, tokens, passwords, and API keys before sharing.
HAR files stay local in your browser in v1. Parsing, scanning, sanitization, and diffing run client-side, with heavy analysis delegated to a Web Worker where practical. Review outputs against your own security policy before sharing any trace.
Primary workbench HAR
Upload a `.har` or HAR-shaped JSON file. CodeAva scans it locally, builds the request explorer, and prepares redaction output.
Why scan first?
- Raw HAR files often contain live cookies, bearer tokens, and request bodies.
- Browser “sanitized” exports are useful, but they are not a complete second-pass review.
- The sanitizer preserves timing, ordering, and most debug context while replacing sensitive values with a consistent marker.
Add field names CodeAva should treat as sensitive. Use comma-separated names like myCompanySession.
Changing presets or custom patterns does not upload anything. Click Re-scan to refresh findings against the current rules.
Upload a HAR to start scanning
The scanner looks through request headers, response headers, cookies, query params, bodies, and vendor-prefixed metadata without sending the file anywhere.
Redact findings to generate a safer HAR
CodeAva preserves JSON validity and request ordering, then swaps flagged values with a consistent marker so the file stays importable.
- 1. Capture the smallest HAR that reproduces the issue.
- 2. Upload it here and review the summary cards.
- 3. Scan for secrets, then redact all or selected categories.
- 4. Preview the sanitized JSON before downloading it.
- 5. Share the sanitized HAR, findings report, or redaction log instead of the raw trace when possible.
CodeAva does not upload HAR contents in v1.
Heavy parsing and scanning can run in a Web Worker so the main UI stays responsive on larger traces.
Always follow your internal handling policy before opening, saving, or sharing customer traffic captures.
Is it safe to share a HAR file?
Raw HAR files are often unsafe to share because they can include session cookies, bearer tokens, signed request headers, query-string secrets, request bodies, response bodies, and customer data captured during the recorded session. A HAR is effectively a serialized network trace, not just a lightweight waterfall screenshot.
Some browsers and tooling now offer a sanitized HAR export option, which is useful, but that should not be treated as a guarantee that every sensitive value was removed. Sanitization logic often focuses on a subset of auth-related fields and may leave secrets behind in query params, POST bodies, response bodies, or vendor-prefixed metadata.
A safer workflow is to review the HAR locally, run a second-pass secret scan, redact what you do not need to share, and then send the sanitized copy instead of the raw trace.
What usually leaks inside a HAR file?
| Location in HAR | What commonly leaks | Why it matters |
|---|---|---|
| Request headers | Authorization bearer tokens, API keys, signed request headers, internal IDs | Headers often grant direct access or expose how the client authenticates against an API. |
| Response headers | Set-Cookie values, token-like headers, debug IDs, internal infrastructure hints | A response can create or rotate sessions, making the HAR unsafe even if the request looked clean. |
| Cookies | Session cookies, refresh cookies, CSRF cookies, vendor auth state | Cookies can represent a live authenticated session or reveal user state tied to a real account. |
| Query parameters | Reset tokens, magic-link tokens, API keys, signed URLs, PII | Query strings get copied widely and are easy to miss during manual review. |
| Request body | Passwords, email addresses, phone numbers, secrets in JSON or form fields | Support reproductions and login flows often place the most sensitive values in POST bodies. |
| Response body | Customer data, access tokens, debug payloads, account metadata | Even if the request is harmless, the response can include sensitive application data. |
| Custom / vendor fields | Tool-specific session values, internal IDs, environment metadata, embedded auth values | Browser- and vendor-prefixed fields are inconsistent and easy to overlook in a manual scrub. |
Why sanitize a HAR even if your browser exported a sanitized one?
Browser sanitization often focuses on a narrower set of auth-related fields such as selected cookies or authorization headers. That still leaves room for secrets to appear elsewhere, especially in query strings, form submissions, JSON bodies, response payloads, or custom tooling metadata.
Support and vendor-share workflows also add context: the right question is not “did the browser scrub something?” but “is this specific file safe enough for this specific audience?” A second-pass review is practical risk reduction, especially when the HAR will leave your internal environment.
How to use HAR files for performance debugging
HAR files are still one of the fastest ways to understand why a page or flow feels slow. The most useful starting points are usually the slowest requests, which domains consumed the most time, and whether payload size or wait time is the bigger contributor.
That means looking beyond a raw waterfall: group third-party traffic, compare before/after captures, separate TTFB from total duration, and look for payload bloat or a new external dependency that changed the shape of the session.
A practical HAR analyzer should help you move from “something feels slow” to “this domain, this request class, and this timing shift changed” without forcing you to inspect hundreds of rows manually.
HAR file privacy checklist
This tool keeps HAR parsing, scanning, redaction, and diffing local in the browser in v1. A Web Worker is used where practical to keep the UI responsive, but sanitization is still a practical risk-reduction workflow rather than a substitute for a full security review.
Overview
HAR files are useful because they capture the real network story behind a bug report: which requests fired, what they returned, how long they took, which domains were involved, and what data was sent or received. That makes them valuable for developers, QA teams, support engineers, agencies, and performance specialists working through a browser issue with evidence instead of guesswork.
They are also risky. A raw HAR can contain live session cookies, authorization headers, CSRF tokens, passwords, customer identifiers, and body content you never intended to hand to a vendor or attach to a ticket. A good HAR workflow needs both network debugging and secret redaction, because speed diagnostics and privacy hygiene usually have to happen on the same file.
CodeAva’s Secure HAR Viewer, Analyzer & Secret Sanitizer combines those jobs into one local-first workbench. You can inspect requests, group third-party traffic, compare before and after traces, scan for leaked secrets, and generate a safer HAR for sharing without sending the original capture to a server in v1.
What this tool helps with
Best for
- Finding the slowest requests quicklyrank entries by total time, wait / TTFB, or transfer size instead of scanning a giant waterfall manually.
- Grouping third-party trafficsurface analytics, CDN, payment, API, and other external request patterns that can change the shape of a session.
- Comparing before / after tracesspot request-count changes, payload shifts, domain changes, and timing regressions after an optimization or release.
- Scanning for leaked auth tokens and cookiescheck headers, cookies, query params, JSON fields, form fields, response bodies, and custom metadata before a file leaves your team.
- Generating a safer HAR for support sharingpreview a sanitized HAR locally, then download the redacted JSON, findings report, or redaction log for a safer handoff.
- Reviewing a HAR locally before a ticket is openedinspect whether the export is already partially sanitized, whether bodies are missing, and whether it contains more customer data than the bug report really needs.
What it does not replace
- Treating browser sanitized export as a complete guaranteesanitized export is helpful, but it does not prove that every secret in the trace is gone.
- Using redaction as a substitute for security reviewheuristic scanning is useful, but a high-stakes incident still needs a deliberate human review process.
- Assuming every HAR is perfectly standards-compliantreal HAR files vary by browser, tooling, and capture settings, so the viewer takes a best-effort, tolerant approach.
How to use
- 1
Export a HAR from your browser
Start the capture before reproducing the issue so the trace includes the full request sequence you care about.
- 2
Upload it into the workbench
CodeAva parses the file locally, builds the request explorer, and starts the secret scan automatically with your current preset.
- 3
Review the performance summary
Check total requests, payload size, slowest entries, domain groupings, and whether a third-party or large response body stands out.
- 4
Scan for secrets
Review findings across headers, cookies, query params, request bodies, response bodies, and vendor-prefixed metadata.
- 5
Redact findings
Use one-click redact-all or selective category redaction, then preview the sanitized HAR locally before you save it.
- 6
Download the sanitized HAR
Save the safer HAR for support or vendor sharing, and export the findings report or redaction log if you need an audit trail.
Common issues and fixes
Assuming a browser “sanitized HAR” is fully safe
Treat browser sanitization as a first pass. Review query params, POST bodies, response bodies, and vendor-specific metadata separately before you share the file.
Forgetting that query params and POST bodies may still contain secrets
Auth flows, password resets, webhook tests, and support reproductions often leak tokens outside headers. Check both structured fields and plain-text body content.
Sharing a HAR directly in Jira or email without reviewing it
Open the HAR locally first, scan it, redact what is not required, and only then send the sanitized copy. Reduce what you capture in the first place when possible.
Relying only on a waterfall and missing the real bottleneck
Use slow-request leaderboards, domain grouping, and before/after diffing alongside the waterfall so new third-party drag or payload bloat stands out faster.
Comparing HAR files without normalizing what changed
A practical diff should handle reordered requests and noisy query params. Compare method, host, path, stable query shape, and request counts instead of raw row order alone.
Importing HARs that are incomplete or tool-specific
Different browsers and exporters include different levels of detail. Missing request or response bodies usually mean the source HAR did not capture them, not that the viewer failed.
Frequently asked questions
Related tools
Browser HAR export guide
Start recording before you reproduce the issue. Export behavior varies by browser and devtools, and some tools offer “sanitized” or “with sensitive data” options that change what ends up in the file.
Chrome
Open DevTools → Network, start recording, reproduce the issue, then use the export option from the network panel. Chrome-based tooling may surface separate export options for sensitive vs sanitized HAR data depending on the version and context.
Edge
Open DevTools → Network, make sure recording is running before the repro, then export the network log. Edge follows the same Chromium-family behavior, so available HAR options can vary with the devtools build.
Firefox
Open Developer Tools → Network, keep the panel recording while you reproduce the issue, then save all as HAR. Firefox exports can differ from Chromium exports, especially around body capture and custom fields.
Safari
Enable the Develop menu if needed, open Web Inspector → Network, start capture before the repro, then export the recorded session. Safari HAR support is practical but can omit fields that other browsers include.
Trust and local processing
In v1, HAR files are processed locally in-browser. No automatic upload occurs when you open this page or choose a file. Parsing, scanning, and diffing can run in a Web Worker where practical so larger HARs are less likely to freeze the main UI.
That local-first design reduces exposure, but it does not remove your internal obligations. A support trace can still contain customer data, auth material, and business-sensitive endpoints, so your normal handling policy still applies before you open, save, or share the file.
The sanitizer should be treated as a quarantine-and-debug step: inspect locally, reduce risk, preserve the useful parts of the trace, and then decide whether the resulting output is appropriate for the intended audience.
Related guides
Third-Party Scripts And INP Optimization
Use HAR evidence to confirm whether external scripts are adding real user-facing drag.
JWT Expiry Debugging
If a token leaks into a trace, decode it locally and inspect why the auth flow failed.
HTTP Security Headers Checklist
Pair session-trace review with response-header hardening so traffic is safer in production.