A bug only shows up after a specific sequence of requests — a login, then a token refresh, then the call that 500s. Describing that in a ticket loses the detail that matters, and "it works on my machine" is not a repro. What a backend engineer can actually act on is the traffic itself: the exact requests, headers, bodies, and responses, in order.
The standard container for that is a HAR file (HTTP Archive) — a JSON format that records a set of HTTP transactions. This guide covers both directions in Rockxy on macOS: exporting captured flows to a HAR you can attach to a ticket, and importing a HAR a teammate sent you so you can inspect it locally. The one non-negotiable step is redacting secrets before the file leaves your Mac, because a HAR carries every header and body verbatim.
What a HAR file actually contains
A HAR is a plain-text JSON document that follows the HAR 1.2 specification. For each request it stores the method, full URL, every request header, query string, POST body, the response status, response headers, and the response body. That completeness is exactly why it makes a good bug report — and exactly why it is a liability if you share it carelessly.
The headers and bodies include whatever your client actually sent: Authorization tokens, session cookies, bearer tokens, and any PII in a JSON body. A HAR pasted into a public ticket is a credential leak. Treat every HAR as sensitive until you have redacted it.
What you will need
- Rockxy on macOS 14 (Sonoma) or later. It is a native app; download it from the Rockxy download page.
- Some captured traffic — the actual sequence that reproduces the bug. If localhost traffic is not showing up yet, fix that first with the localhost capture guide.
- Redaction configured, so tokens and cookies are stripped before anything is written to disk. Rockxy's Redaction covers
Authorizationheaders, cookies, bearer tokens, and PII. - For importing: a
.harfile from a teammate, a browser's DevTools, or another proxy tool that writes HAR 1.2.
Step 1 — Redact secrets before you export
Do this first, not last. If you redact after exporting, the un-redacted file has already touched your disk and possibly your clipboard. Configure Redaction so that sensitive fields are removed from the data on the way out.
At minimum, redact Authorization headers, session and auth cookies, and bearer tokens. If the request or response bodies carry PII — emails, names, account numbers — redact those too. The goal is a file that reproduces the shape of the bug without carrying anything that can be replayed against a real account.
The details of what Redaction masks and how the rules are scoped are covered in Local HTTP Debugging: Security, TLS, and Redaction. Configure it once and it applies to every export from then on.
Step 2 — Select the flows and export to HAR
You rarely want to export the entire capture — that dumps unrelated noise into the file and makes it larger and harder to review. Filter or search the traffic list down to the requests that reproduce the problem, then select that set and export it. Rockxy writes the selection as a HAR 1.2 file.
Keep the exported set as small as the repro allows. A three-request HAR that shows the login, the refresh, and the failing call is more useful to a backend engineer than a thousand-row capture they have to dig through. The exact menu labels for exporting live in the sessions and export docs; the capability is a standard export-to-HAR of whatever flows you have selected.
What you should see in Rockxy: a .har file written to the location you chose, sized roughly in proportion to the number and size of the flows you selected. Open it in a text editor and confirm the top of the JSON reads like a HAR log — a log object with a version and an entries array — and, critically, that the fields you redacted are masked and not sitting in plain text.
The screenshot below shows Rockxy's session export view: the selected flows on the left, ready to be written out as a HAR bug report after redaction.
Authorization headers and cookies first, then export only the requests that reproduce the issue.Step 3 — Verify the file before you attach it
A HAR is only useful if it opens and reads back correctly, so verify it before it goes anywhere. Two quick checks catch almost every problem:
- It parses. HAR is JSON, so a truncated or malformed file will fail to parse. Re-import it into Rockxy (Step 4) or open it in any HAR viewer and confirm the entries appear.
- It is clean. Search the raw JSON for the header names and token prefixes you meant to redact. If
Bearer, a real cookie value, or an API key still appears, your redaction did not cover that field — fix the rule and re-export. Do not hand-edit the file, because a hand-edited HAR is easy to break and easy to miss a second copy of the same secret.
Step 4 — Import a HAR someone sent you
The other direction is just as common: a teammate captured the failing sequence and sent you a .har, and you want to read it with real tooling instead of scrolling raw JSON. Import the HAR file into Rockxy and its transactions load into the traffic list as flows you can inspect.
What you should see in Rockxy: each entry from the HAR appears as a row in the list, with method, URL, and status, exactly like live traffic. Selecting a row shows the request headers, request body, response headers, and response body that the file recorded. From there you can read, search, and filter the imported flows the same way you would a live capture.
One thing importing does not do: it does not replay anything. Importing loads a recording so you can look at it. To actually re-send one of those requests against a live server, use Replay or Compose on the imported flow — a HAR is a snapshot of what happened, not a live connection.
If it does not work
The exported HAR still contains a token or cookie. Your redaction rule did not match that field. Check that the rule covers the exact header name or body path — a rule for Authorization will not catch a custom X-Api-Key header — then re-export. Never patch the leaked value out by hand and ship the same file.
The import shows fewer requests than you expected. The HAR only contains what was captured when it was written. If a request never reached the tool that produced the file, it is not in the HAR and cannot appear on import. Ask for a fresh capture that includes the missing step.
A body looks like a wall of base64. The HAR spec represents binary response bodies — images, compressed payloads, protocol buffers — as base64-encoded text with an encoding marker. That is expected; the bytes are intact, they are just not human-readable in the raw file. Rockxy decodes what it can when it shows the flow.
The file will not import. Confirm it is valid HAR 1.2 JSON. A file that was truncated mid-write, or that is actually a different export format with a .har extension, will not parse. Ask the sender to re-export.
Limitations to keep in mind
- A HAR carries sensitive data by design. Redaction is a step you own, not an automatic guarantee — verify every file before sharing it.
- A HAR is a snapshot, not a live session. It records what happened once. It does not reconnect, and it does not update.
- Importing does not replay. Loading a HAR lets you read it; re-sending a request is a separate, deliberate action via Replay or Compose.
- Binary bodies are base64. Per the HAR spec, non-text bodies are encoded, so the raw file is not always readable without a tool that decodes them.
Next steps
Exporting and importing a HAR turns "it broke for me" into a file a backend engineer can open, read, and reason about — as long as you redact first and verify before you send. Configure Redaction once, export only the flows that reproduce the issue, check the file, and attach it.
From here, if you are handing work to teammates regularly, read how to share a debugging session with your team for the wider workflow, tighten what leaves your Mac with security, TLS, and redaction, or make sure the traffic is being captured in the first place with the localhost capture guide. The full export options live in the sessions docs.
