Open a HAR file and find the requests that matter: failures, slow responses, missing data, and headers that should not be forwarded. The viewer below runs entirely in your browser. The file is not uploaded to Screendesk or to any other server.
Use it when a customer or colleague sends a .har file and you need a quick first read before escalating. If you still need the file itself, follow the steps to get a HAR file in Chrome, Edge, Firefox or Safari.
Drop a .har file here or
The file is read by this page in your browser. It is not uploaded to Screendesk or anywhere else.
to see how it works.
This removes only what is listed above. Personal data inside URLs, page content or other headers can remain, so review the file before you share it.
What the HAR analyzer shows
A HAR (HTTP Archive) file is a JSON log of the network requests a browser recorded while its developer tools were open. Each entry stores the request, the response, and how long each phase took. The viewer turns that log into four views:
- Summary: number of requests, failed requests, data transferred, and the time span covered by the recording.
- Findings: plain-language notes on 5xx server errors, 4xx client errors, requests that never received a status, requests that took a second or longer, and cookies or authorization headers present in the file.
- Request list: status, method, URL, type, size, time and a waterfall. Filter by failed or slow requests, by type, or by part of the URL.
- Request details: select a URL to see query parameters, request and response headers, the timing breakdown and the saved response body (text only, first 4,000 characters).
How to read the results
Start with the request that matches what the customer was doing when the problem happened. A failed analytics or advertising request is rarely the cause of a broken checkout. The status code tells you where to look next.
| Status | Usual meaning | Useful next step |
|---|---|---|
| 200–299 | The server answered successfully. | If the screen still looked wrong, check the response body for missing or unexpected data. |
| 301, 302, 307, 308 | Redirect to another URL. | Check where it redirects. Loops or redirects to a login page often point to session problems. |
| 400, 422 | The server rejected the input. | Read the response body. It often names the invalid field. |
| 401, 403 | Not signed in, or not allowed. | Check the customer’s session, role and permissions before escalating. |
| 404 | The requested resource was not found. | Compare the ID or path in the URL with the record the customer expected. |
| 429 | Too many requests. | Note the time and frequency. Rate limiting may be intentional. |
| 500–599 | The server failed to handle the request. | Escalate with the URL, time, and any request ID in the response headers or body. |
| No status | No response was recorded. | The request may have been blocked (CORS, an extension, a firewall), cancelled, or still pending when the file was saved. |
For slow requests, open the details and look at the timings. A long wait (time to first byte) usually means the server took a long time to respond. Long dns, connect or ssl phases point to network or connection setup. A long receive phase with a large size suggests a heavy download. A long blocked phase means the browser queued the request behind others.
A five-minute triage routine for support
- Confirm the file covers the problem. Check the recorded span and find a request for the page or action the customer described. If it is missing, recording started too late.
- Filter to failed requests. Ignore third-party analytics first. Focus on your product’s own domain and API paths.
- Read the failing response. Error messages, validation details and request IDs are often in the body or headers.
- Check slow requests if the complaint is about speed rather than an error.
- Sanitize before you escalate. Download a sanitized copy, then attach it to the internal ticket with the request URL, time and status you found.
What the sanitizer removes, and what it does not
HAR files can contain session cookies and access tokens. Anyone holding a valid session cookie may be able to act as that user until the session expires. Recent versions of Chrome and Edge export a sanitized HAR by default, which leaves out Cookie, Set-Cookie and Authorization headers. Other browsers, older versions, and exports made “with sensitive data” can still include them.
The Download sanitized HAR option in this viewer creates a new copy. It does not change your original file. Depending on the boxes you tick, it:
- empties the request and response cookie lists and removes these headers: Cookie, Set-Cookie, Authorization, Proxy-Authorization, X-API-Key, X-Auth-Token, X-CSRF-Token and X-XSRF-Token;
- replaces the values of URL, query and form parameters whose names contain token, key, secret, password, auth, session, sig or code with
REDACTED. This is a name match, so a parameter such aszipcodeis also redacted; - optionally removes response bodies and request bodies.
It does not find personal data in URL paths, page content, custom headers with other names, or response bodies you choose to keep. Review the file before sharing it, and share it only through your ticketing system or another restricted channel.
When a HAR file is not enough
A HAR file shows network traffic. It does not show what the customer saw, what they clicked, or the browser console errors (Chrome and Edge do not include console messages in a HAR export). It also needs the customer to open developer tools before reproducing the problem, which many customers find difficult.
If you often ask customers for HAR files, a screen recording request can be easier for them. With Screendesk, an agent sends a recording link from the helpdesk. The customer records the problem in a desktop browser without installing anything, and in supported helpdesk workflows the recording returns to the ticket. Console and network logs are captured on the Enterprise plan with the supported capture setup. On other plans, use the recording to see the problem and a HAR file when engineering needs network detail.
Frequently asked questions
Is my HAR file uploaded when I use this viewer?
No. The page reads the file with your browser’s file API and builds the tables locally. Nothing in the file is sent to Screendesk. The blog’s analytics can record that the viewer was used and how many requests the file had, but never the file’s contents.
Can I open a HAR file in Chrome instead?
Yes. In Chrome or Edge DevTools, open the Network panel and drag the file onto the request table, or select Import HAR in the Network panel’s action bar. Firefox’s Network Monitor has an Import HAR option too. Google’s Admin Toolbox also offers a HAR analyzer.
Why does the HAR file have no requests?
Developer tools record only while they are open. Ask the customer to open the Network panel first, enable Preserve log (Chrome and Edge) or Persist Logs (Firefox), reproduce the problem, and then export. Clearing the filter box before exporting also makes sure every request is included.
How large can the file be?
The viewer accepts files up to 300 MB, and the request list shows up to 500 matching rows at a time. Very large files usually mean recording ran much longer than needed. A short recording focused on the failing action is easier to analyze.
