Skip to main content
New insight available. View changelog →
Start Tier 1

Troubleshooting · SupportRoadmap Docs

How to capture and safely share a HAR file

A HAR (HTTP Archive) file records browser network activity for a page session. It is useful evidence for SaaS support and engineering, but it can include cookies, tokens, headers, query parameters, and request or response bodies. Always review a HAR before sharing it.

By Tom Ulman · Published · Last reviewed

Security warning

HAR files can expose sensitive information, including cookies, authorisation headers, session information, tokens, request and response bodies, query parameters, and personal or customer data. Treat a HAR like a temporary credential until you have reviewed it.

Support teams use HAR files when a SaaS bug depends on a sequence of network calls that is hard to describe in prose. Engineering can replay the timeline; you still own safe capture and sharing.

What a HAR can contain

  • Cookies and `Set-Cookie` values
  • Authorisation headers and API keys
  • Session identifiers and tokens in headers, bodies, or query strings
  • Request and response bodies (account data, emails, payloads)
  • Internal URLs, tenant IDs, and customer-identifying paths

Chrome export behaviour (verify in your browser)

Current Chromium-based Chrome DevTools exports HAR files in a sanitised form by default. That default aims to exclude sensitive header values such as cookies and authorisation data. Chrome also provides a path to export a HAR with sensitive data after you explicitly allow it in DevTools settings and choose the sensitive export option.

Sanitisation is a safety improvement, not a guarantee that every sensitive value is removed. Bodies, query parameters, and application-specific tokens can still leak. Always review the file before sharing.

Follow the official Chrome DevTools Network documentation for the current export steps, because DevTools UI labels can change between releases.

How to capture a useful HAR

  1. Open DevTools → Network. Enable “Preserve log” if navigations are involved.
  2. Clear the log, then reproduce only the failing path.
  3. Prefer the default sanitised export unless engineering explicitly needs sensitive headers.
  4. If a sensitive export is required, enable the DevTools preference that allows it, export deliberately, and store the file securely.
  5. Open the HAR locally and search for secrets before attaching it anywhere.

Safe review-and-sharing checklist

  • Search for `cookie`, `authorization`, `token`, `password`, `secret`, `api_key`, and session IDs.
  • Strip or redact customer PII from bodies you do not need.
  • Share only with people who need it, via your company’s approved channel.
  • Delete local copies when the investigation ends, following your data-retention rules.
  • Record in the ticket what was redacted and which request failed (method, path, status).

Realistic SaaS example

A customer’s “Invite teammate” button returns a generic error. Your sanitised HAR shows `POST /invites` → `409` with a conflict body about an existing email. That is enough for a clear reply and a product bug check. You do not need an unsanitised HAR containing session cookies for that outcome.

Related learning

Limitations and common mistakes

Do not email unsanitised HARs to personal inboxes or public tickets.

Do not assume “sanitised” means “safe for customers or contractors without review.”

Do not capture an entire day of browsing; keep the reproduction minimal.

Related concepts

Primary sources

Prefer an ordered path? Open the related roadmap skill and work through it with the curated resources.

Practise this skill