HAR Sanitizer

Preparing a browser capture for support means keeping the evidence of a failure while reducing the session data shared with it. A HAR, short for HTTP Archive, is a JSON record of captured requests and responses. Request addresses, status codes and timings can help explain a failed sign-in, an unexpected redirect or a slow page.

The contents can extend well beyond a list of addresses. Each entry describes an outgoing request and its response. Headers carry information such as content types and authentication details, while bodies hold submitted or returned content. Depending on the capture, that content might include a form submission, an error message, a document or an application response containing personal records.

One sensitive value may appear more than once. A cookie can be recorded in both an HTTP header and a separate cookie list. A query parameter can occur in the request address and again in a structured parameter list. Removing a visible password or one authorization header can therefore leave another stored copy behind.

Structural sanitization applies removal rules to known fields and configured names. Clearing credential values and omitting captured bodies can preserve the request sequence and timing evidence needed for troubleshooting. The tradeoff is lost detail: a removed response body may have contained the message needed to understand an application error. The original capture and the version prepared for sharing serve different purposes.

These rules cannot recognize every private detail by its meaning. Customer information in a URL path, a page title or an unfamiliar field may remain, and encoded text can conceal information from a simple visual check. Human review of the retained content is part of preparing a support file. A redaction count does not establish anonymity or prove that every secret has been removed.

How to Use This Tool:

Start with one complete capture intended for review. Load sample provides synthetic data if you want to explore the process first.

1. Paste HAR JSON into HAR capture, or choose Browse file and select one local .har or .json file. You can also drop a single file into the input.

   Uploaded files above 256 KiB show a labeled preview of the first 16,384 characters. Sanitize still uses the complete file. Edit full source makes the full text editable and may pause the tab for a large capture. Pasting into the preview replaces the entire input.

2. Open Advanced when your application uses additional sensitive names. Enter them in Additional sensitive headers or Additional sensitive parameters, separated by commas. Empty additions leave the default removal policy in place.

3. Select Sanitize. A completed run shows Review before sharing and the number of changed slots.

   If Capture needs attention appears, correct the reported input problem and run again. For incomplete JSON, load or paste the complete HAR export. A failed run provides no partial result to download.

4. Inspect Sanitized capture and Review limits. Use the Redaction ledger to check the locations changed, then examine retained addresses, descriptive text and unfamiliar fields before sharing.

5. Choose Download HAR or Copy text from Sanitized capture once the remaining content is suitable for the recipient. Editing the capture or additional names removes the previous results from view, so run Sanitize again before exporting.

Interpreting Results:

A changed slot is a stored location altered by a removal rule. The same token recorded in a URL and a separate query list contributes two changes. Counts describe edits, not distinct secrets, affected people or the proportion of sensitive data found. Zero changes means that the selected policy made no further removals; retained content still needs review.

• Entries counts captured entries. Changed entries counts distinct entries with at least one recorded removal. Changes outside the entry list can increase changed slots without increasing changed entries.
• The Redaction ledger records the category, request/response/document context, entry index, structural path and action. Entry indexes start at zero. Removed values and raw URLs are absent, and unfamiliar property names become numbered placeholders. The ledger does not inventory sensitive information that remains.
• Removal distribution groups the same changes by category and context. Its totals equal the ledger row count and the changed-slot total. A larger bar represents more edited locations.

Recorded timings and body or transfer sizes still describe the original capture. Removing captured text does not recalculate those measurements or make the reported body size zero. They remain useful diagnostic evidence, but they do not describe the size of the sanitized file.

Large output previews may be shortened. HAR copying and downloading include the complete result. The ledger displays 100 rows per page, while its exports include every row. Review limits displays up to 100 notes; its Copy text action includes all notes.

Technical Details:

HAR stores headers, cookies, query parameters and body text in separate locations. Redaction must address each representation independently. HAR 1.2 defines the record structure; the sensitive-name lists below are practical removal choices, not an official or exhaustive classification of secrets.

Transformation Core

The removal policy uses three operations: empty a value, replace it with [REDACTED], or omit a property. The surrounding record remains unless a rule removes the whole property or subtree.

Comment and underscore-property removal takes precedence over further processing of those properties. It also applies inside unfamiliar objects. Other unrecognized fields remain and are identified by structural location for review; a familiar-looking name inside an unknown object does not automatically receive a HAR-specific redaction rule.

Default names and literal additions

Default sensitive headers

cookie, set-cookie, authorization, proxy-authorization, x-api-key, x-auth-token.

Default sensitive parameters

token, access_token, password, api_key, client_secret, code, id_token, refresh_token.

Matching trims surrounding whitespace and treats ASCII uppercase and lowercase letters alike. For example, Authorization and AUTHORIZATION match the same header rule. Parameter matching follows that same policy even when an application distinguishes parameter-name casing.

Additional names extend these lists. Commas separate names, empty items are ignored, and duplicates are counted once after normalization. Punctuation is literal: token* matches that name, not every name beginning with token. Additions cannot disable mandatory removal or retain captured bodies.

URL handling and a worked path

Supported URL locations are the request URL, the response redirect URL, and Location or Referer header values in either header list. Request URLs must be absolute. Nonempty relative redirect and header URLs are resolved against the entry's original request URL and written as absolute URLs.

URL query names are decoded once before matching. Names in the separate HAR query list are matched directly. Values are not recursively decoded or searched for secrets, so an encoded object under an unlisted parameter name can remain.

A synthetic HTTPS request shows how several removals can occur within one URL. The components below describe one address before and after sanitization:

1. Start with username user, password pass, host example.test, path /api, query string %74oken=a&token=b&keep=1 and fragment part. Decoding the first query name produces token, so there are two matching token occurrences.
2. Clear the username, password and fragment. Replace both token values with [REDACTED], leaving keep=1 in its original position.
3. Keep the HTTPS protocol, host example.test and path /api. The query string becomes token=%5BREDACTED%5D&token=%5BREDACTED%5D&keep=1; the username, password and fragment are absent. The marker's brackets are percent-encoded in the URL; query-list and form values contain the literal marker.

Those edits contribute five changed slots within the URL. Copies of its parameters in the separate query list are counted independently. URL serialization can also normalize host casing, default ports and encoding. Non-sensitive parameter meanings and duplicate order are retained, but the original URL spelling is not guaranteed. Changes caused only by serialization do not add redaction counts.

Adding Location or Referer as a sensitive header empties its entire value instead of cleaning individual URL components. The input URL must still pass validation before removal. Parseable non-HTTP URLs can also be processed, but opaque paths or embedded payloads remain a review concern and receive a warning.

Accepted captures and limits

Limits apply to the original input, including content that would later be deleted. A successful run confirms the required and targeted structures can be processed; it is not an exhaustive HAR schema validation.

Files must decode as valid UTF-8. One leading byte-order mark is ignored when parsing JSON. The log needs a creator with string name and version fields and an entry list. Each entry needs request, response, cache and timing objects. Targeted headers, cookies and query-list items need string names and values; optional body and form fields must have the expected types. Invalid targeted content or an unparseable supported URL blocks the entire result.

Parsed numbers must be finite. Integer-valued numbers outside the range from −9,007,199,254,740,991 to 9,007,199,254,740,991 are rejected. Accepted fractional values retain their parsed numeric precision without additional rounding. Timing sums and capture-size measurements are not recomputed.

Entry count and order, request methods, response statuses, page identifiers and references, recorded times, MIME types, encoding information and cache data are retained alongside other fields outside the removal rules. Cookie attributes and uploaded form filenames remain too. Removed bodies, comments and extensions cannot be reconstructed from the sanitized HAR. For comparable removal counts, use the same original capture and additional-name lists; a second pass over already sanitized content can report zero changes.

Privacy Notes:

Capture processing takes place in the current browser tab. The capture, filename, additional names and results are not uploaded, saved in browser storage or placed in a shareable page address. The selected local file is left unchanged. Recorded URLs are not visited, requests are not replayed, and no support ticket is submitted.

• Copying and downloading create the copies you explicitly request. Those copies can still contain retained capture data.
• Clear resets the loaded capture, additional names, previews and results. It does not delete the original file, remove downloads already saved or erase text previously copied to the clipboard.
• Opening Removal distribution may load separate chart display resources. Those requests do not contain the capture. HAR and ledger exports remain usable if the chart is unavailable.

Worked Examples:

References:

• HAR 1.2 Spec, Software is hard.
• URL Standard, WHATWG, 19 October 2026.