Open a .har file (DevTools' "Save all as HAR") and get a sortable, filterable request
list, headers/cookies/bodies you can actually navigate, and a real diff between two captures --
entirely in your browser.
A HAR is JSON, so this isn't a separate tool bolted onto Json Web Viewer -- it's a lens over the same tree navigation, structural diff, and large-document handling the rest of the app already has. That's also the honest differentiator over a generic HAR viewer: a JSON response body is parsed and shown as real, navigable JSON -- expand it, search it, copy a path out of it -- not a string you have to eyeball.
Diffing two captures is the gap most HAR tools leave open. Requests are matched by method and URL; timing, timestamps, and connection details are excluded from the comparison so the diff shows what actually changed between "it worked yesterday" and "here's today's capture" -- not noise every capture would show anyway. A changed JSON body shows exactly which field changed, not "the whole response is different."
Large captures are a measured limit, not a guess -- the request list stays responsive well past 100,000 entries; diffing (the genuinely expensive part) is capped at the first 2,000 matched request pairs, a number chosen from real timing measurements rather than an arbitrary round figure.
Open a sample capture in HAR view →
The link above loads a two-request sample (one JSON list response, one failing POST) straight into
HAR view -- reached from the editor's overflow menu ("HAR view") any time you paste or open a
.har file.
HTTP Archive (.har) is a JSON format that browser DevTools (Network panel, "Save all
as HAR") and API testing tools export: every request and response in a page load or session, with
headers, timing, cookies, and bodies.
No. Parsing, browsing, and diffing all run entirely in your browser. Loading a second capture to
diff against uses a local file read (FileReader) -- neither capture is ever sent over
the network, including to compare them against each other.
Building the request list stays fast well past 100,000 entries -- entry count isn't where a HAR's size risk lives; real captures are usually large in response-body bytes, not request count. Diffing two captures is the genuinely expensive operation, so it's measured and capped: full diffs are computed for the first 2,000 matched request pairs, chosen from real timing measurements to stay well under a second even in a mixed realistic capture. Beyond that, matched/added/removed counts stay exact; the deep per-pair diff for the remainder is skipped rather than freezing the tab.
By method and URL (including the query string). Repeated identical requests to the same URL are paired in the order they occur in each capture -- the right call for retries and polling, though it means a genuine reordering of otherwise-identical repeated requests isn't distinguished from no change at all. Fields that are expected to differ between two unrelated runs -- timing, timestamps, connection IDs -- are excluded from the diff so it shows what actually changed, not noise.
As JSON. A body detected as JSON (by content type or content) is parsed and compared key by key, so a single changed field shows as one specific change -- not "the whole body is different" the way a generic HAR viewer or a text diff would report it.
Comparing two plain JSON documents instead of network captures? See JSON Diff.