How to Read a HAR File and Find Network Errors

A HAR file—short for HTTP Archive—is a record of activity between a web browser and websites or web services. It can help you investigate a page that loads slowly, an upload that fails, or an error that appears only in a browser. Reading one means tracing the recorded requests and responses, rather than treating the file as a simple report with one overall answer.

You can inspect a HAR file in a browser’s developer tools or a dedicated HAR viewer. The exact interface varies, but the main information is similar: request URL and method, response status, headers, transferred content, and timing. Treat the file as sensitive: it may include session cookies, authorization data, personal information, or the contents of form submissions.

What You’ll Need

A HAR file, usually ending in .har, captured while the issue occurred.
A current web browser with developer tools, or a trusted HAR viewer that can open JSON-based HAR files.
The approximate time and action that produced the problem, such as clicking Sign in or loading a page.
Permission to inspect or share the file. Do not upload it to an online viewer unless you understand its privacy and data-handling practices.

Step-by-Step

Protect the file first. Keep the original somewhere private and work on a copy. A HAR can expose account identifiers, search terms, private URLs, cookies, and request or response data. Before sharing it, remove or redact sensitive content using a method you trust; deleting a visible line in a viewer may not remove the data from the underlying file.
Open it in a suitable viewer. In a browser’s developer tools, look for the Network panel and its option to import or load a HAR file. The menu path and button names can differ slightly by browser version. Alternatively, open the file with a trusted local HAR viewer. If you use a text editor, remember that a HAR is structured JSON, so a viewer is usually easier to navigate.
Find the relevant time or request. Use the list of network entries and look for the page, image, script, API call, or upload related to the issue. Sort or filter by URL, status, type, or time if the viewer offers those controls. Match the entry to the action you remember; a file may contain hundreds of unrelated background requests.
Check the request method and URL. The method—often GET or POST—shows what kind of action the browser made, while the URL identifies the destination. Confirm that the request is aimed at the expected host and path. Be cautious: query strings and URL paths can themselves contain private values.
Read the status code. A response in the 2xx range generally indicates success; 3xx indicates a redirect; 4xx usually points to a request, access, or authentication issue; and 5xx generally indicates a server-side problem. These are clues, not diagnoses. A request can fail before receiving an HTTP status, and a successful status does not guarantee that the page behaved correctly.
Compare request and response details. Open the entry’s headers and, where available, its payload or response tab. Request headers show what the browser sent; response headers show what the server returned. Look for relevant clues such as content type, cache behavior, redirects, or an error message. Do not paste authorization headers, cookies, or private payloads into public chats or tickets.
Inspect timing and size. HAR viewers commonly break request time into stages such as waiting, connection, sending, and receiving. A long wait before the response may point toward server processing or network delay; a long download may reflect a large response or a slow connection. Timing labels and breakdowns differ among tools, so interpret them as evidence rather than proof of a specific cause.
Follow redirects and dependencies. If the entry has a 3xx status, inspect the next request to see where the browser went. For a page that appears incomplete, check whether a script, stylesheet, font, or API request failed. A page’s visible symptom may be caused by a separate request, so trace related entries around the same time.
Summarize only what the log shows. Record the request URL in a suitably redacted form, method, status, relevant timing, and a short description of the response. Separate observations from guesses—for example, “the request returned 403” is an observation, while “the account lacks permission” needs confirmation from the service owner.

Common Mistakes

Assuming every red entry is the cause. Browsers may make optional requests that fail without breaking the page. Prioritize entries tied to the reported feature and reproduce the issue if possible.
Reading a status code in isolation. A 200 response can contain an application-level error, while a 404 may be expected for an optional resource. Read the response and the surrounding requests.
Confusing elapsed time with server time. A total request duration can include connection setup, waiting, and transfer. It does not always measure how long the server spent processing.
Sharing an unredacted HAR. These files are not automatically safe just because they are diagnostic logs. Remove sensitive data before sending one, and use the recipient’s approved secure channel.
Editing the only copy. Preserve the original so you can check whether redaction or conversion changed the evidence.

Tips

Capture a fresh HAR while reproducing the issue, and start recording before the action that fails. Some tools let you preserve the log across page navigation.
Clear or limit unrelated activity before capturing, when practical, so the useful request is easier to find. Avoid changing browser settings that could alter the behavior being investigated.
Use filters for the affected host, file type, or status, but return to the full request list when checking redirects and dependencies.
When asking for help, include the browser and operating system, the steps that reproduce the issue, and a redacted summary of the relevant entries—not just the HAR file.
For a file that will not open, check whether it is actually a HAR/JSON file and whether it was truncated during saving or transfer. A very large HAR may need a local tool with adequate memory.

Troubleshooting

The viewer says the file is invalid: Confirm that you selected the HAR file itself, not a screenshot or compressed archive. If it is text, inspect a copy to see whether it begins with valid JSON structure; do not manually alter the original. Capture and export the log again if the file is incomplete.

You cannot find the failed request: Reproduce the problem with the Network panel recording, then search for the affected domain or resource type. Check whether the browser navigated to another page, since the relevant request may be in a preserved log or a separate capture.

The log shows no obvious error: Look for redirects, response content, console errors, blocked requests, and application-level messages. Some failures occur in browser code after a successful network response, so a HAR may need to be considered alongside the browser console.

The file is too large or slow to open: Try a trusted local viewer or split the investigation by capturing only the steps needed to reproduce the issue. Do not use an untrusted online service as a shortcut when the log could contain private data.

Someone needs a HAR for support: Ask what information they need and how to send it securely. Remove cookies, tokens, personal details, and unrelated requests before sharing, while preserving enough context to explain the failure.

Frequently Asked Questions

Is a HAR file just a text file?

It is generally a JSON-formatted text file, but its nested structure is easier to read with a HAR viewer. A text editor can still help confirm that the file is readable or inspect a small section.

Can I read a HAR file in Chrome or another browser?

Many browsers provide a Network developer-tools panel that can import or display HAR data. The exact menu and supported features vary slightly by browser version; a dedicated local viewer is another option.

What does a 401 or 403 mean in a HAR?

A 401 commonly indicates that authentication is missing or not accepted, while a 403 commonly indicates that access is refused. The service’s behavior can vary, so check the response details and avoid sharing any credentials in the log.

Does a HAR file include passwords?

It can contain sensitive request data, cookies, tokens, and sometimes submitted form information. Do not assume passwords or other private values are absent; inspect and redact the file before sharing it.

Can a HAR file prove what caused a website problem?

It can show what requests were made, what responses arrived, and how long stages took. It may narrow down the cause, but it does not always reveal why a server or browser produced that result.

Further reading: Mozilla Developer Network. Details can change, so check the official page for anything that matters to you. Spotted a mistake? Tell us. How we write an answer.