HAR → JSON & HAR → cURL

HAR files — short for HTTP Archive — are the standard way to capture and share a browser's network activity, and the format ends up being central to almost any web debugging session that involves figuring out why a page is slow, why an API call is failing, or what data is actually moving between the client and the server. Every modern browser's DevTools network panel can export to HAR with a single click, producing a JSON file containing every request, response, header, timing, and (optionally) body that occurred during the recording. The trouble is that the resulting HAR file is essentially unreadable in raw form — verbose, deeply nested, full of metadata that nobody reads, and including content most people would rather not share by accident. This tool is the bridge between the noisy raw HAR and something you can actually work with.

The most common reason people convert HAR files is to share them with teammates while debugging. A backend developer hands the frontend developer a HAR file showing a failing API call; the frontend developer opens it expecting to find the issue in five minutes and instead spends fifteen scrolling through hundreds of unrelated tracking pixel requests, font preloads, and CDN-served static assets that make up modern page loads. Filtering down to just the relevant requests, by domain or by status code or by content type, is what turns a HAR file from a haystack into a focused debugging artifact. The tool here exposes those filters as one-click operations, so the back-and-forth of 'can you send me just the API requests' becomes unnecessary.

Privacy considerations are central to how HAR sharing should work, because HAR files often contain content that shouldn't leave the company. Authorization headers carrying bearer tokens, Cookie headers carrying session IDs, request bodies containing user input, response bodies containing user data — all of these end up in HAR files unless they're deliberately stripped before sharing. The default behavior here masks the obvious secrets (Authorization, Cookie, common token parameter names) automatically, which catches the most common accidental disclosure pattern. For HAR files that contain genuinely sensitive data beyond those defaults, the rule is to be deliberate about what gets shared and what doesn't, and to verify the masking before sending the file outside the team.

HAR-to-cURL conversion is the other half of this tool that earns the most regular use. Reproducing a failing request from a HAR file is one of the most common debugging tasks: you see the request that failed in DevTools, you want to run it again with slight modifications to see what changes, but reproducing it manually requires copying the URL, headers, body, and method into a cURL command character by character — slow and error-prone. The HAR-to-cURL conversion produces a ready-to-run cURL command that's byte-identical to what the browser sent, which means running it from the terminal reproduces the exact request the browser made. From there, you can modify pieces (try with a different Authorization header, omit a particular cookie, change a query parameter) to isolate what's actually causing the failure.