What this HAR checker actually checks
A HAR is a JSON network recording. This checker examines each recorded request URL, request and response header names, URL query parameter names, and structured form parameter names. Its built-in rules flag names such as Authorization, Cookie, Set-Cookie, X-API-Key, token, password, session and secret. It also lists requests recorded over a protocol other than HTTPS. You can add application-specific names, such as custom_token, in the second input. The report counts requests and flagged requests, identifies the affected field names, and offers JSON and CSV exports for your own review.
A worked example you can reproduce
The included fictional capture has two requests. The first is an HTTPS API call with an Authorization header and an api_key query parameter. Those two names produce one sensitive-field finding for that request. The second uses HTTP rather than HTTPS, so it produces an unencrypted-request finding. The sample therefore contains two requests, one flagged request and two findings. All example credentials are fictional. Use Load example inside the workspace; the demonstration does not contact either example host.
How to interpret a finding
A flagged field name is a review prompt, not proof that a usable credential is present. A cookie may be harmless, and a field with an innocuous name may contain a secret that these rules cannot recognize. Review the original capture locally and decide which material is safe to share. The checker does not open request URLs, replay HTTP requests, verify credentials, inspect your live browser session or contact an external service. It does not decode arbitrary response bodies or inspect unstructured JSON request bodies for every possible secret.
Sanitized HAR exports still deserve review
Chrome provides a sanitized HAR export that excludes certain sensitive headers by default. That is a useful starting point, but it is not the same as a guarantee that every URL, form field or application payload is free of private information. This tool performs a separate, deliberately bounded field-name review. Consult the Chrome documentation linked below for export options. Do not enable sensitive exports merely to try the checker; the fictional example is sufficient to learn the workflow.
Local processing and report handling
The workspace runs in a sandboxed frame with network connections disabled. Selecting a file reads it into that browser tab; it is not uploaded to Utility Matrix. The parent page receives only fixed interaction labels, never the file content, request URLs or calculated findings. The exported report may include hostnames, URL paths and field names, so review it before sharing. This is a checker, not a HAR sanitizer: it does not produce a cleaned HAR file. Clearing the workspace removes its current input and output from the interface; closing the tab ends the in-memory session.
Limits and the next useful step
Use this as a preliminary sharing check, not as a security audit or privacy certification. Very large captures can consume browser memory; narrow the capture to the problem being investigated. A clean result means only that the implemented rules found no matching fields in the supplied recording. For suspected secrets in source files rather than network recordings, use the related source-code scanner. For deployed response-header configuration, use the separate header checker. Neither related task is automatically completed by a HAR review.