~ $ har-to-mocks ./your-file.har ./mocks
A command-line tool that turns the HAR file from your browser's Network tab into a folder of JSON mocks. Real responses, one file per endpoint, readable by MSW, Playwright, connect-api-mocker and Chrome DevTools Local Overrides.
No account, no config file, no signup. Nothing is written unless you give it an output folder, and --dry-run shows every file before it does.
$ npx har-to-mocks ./your-file.har ./mocks --dry-run
You already have the perfect mock data. It's in your Network tab.
Open the Network tab, use your app, then "Export HAR..." in Chrome or "Save All As HAR" in Firefox. Include content so the responses are in the file.
Filter to the API calls you want, preview the table and the folder tree, then write one JSON file per endpoint.
npx har-to-mocks ./file.har ./mocks --url=/api
Load it with mocks-to-msw, mocks-to-playwright or connect-api-mocker, or select it in Chrome's Sources → Overrides. The UI now runs on your recorded responses.
Typing JSON for a 40-field response means typos, missing fields, and shapes that drift from the real API. Recording the real response takes seconds and is exact by definition.
Frontend work stalls. Recorded mocks let the UI run fully offline with production-shaped data.
One set for dev, another for Storybook, another for tests. har-to-mocks produces one folder of JSON that MSW (dev, Storybook and tests), Playwright, connect-api-mocker, and Chrome overrides can all read.
QA or a teammate exports a HAR from the broken session. You turn it into mocks and replay the exact state locally, or load it as a Chrome override on production without touching code.
--url substring, --method (GET, POST, PUT, DELETE, PATCH), --type (xhr, fetch, document). Defaults: GET and xhr.
See create, update or skip per row and the exact folder tree, with [UPDATE] on files that already exist.
-i gives a checkbox list with the focused endpoint's JSON response rendered below it (up to 12 lines), then a confirm step. ↑/↓ navigate, Space toggle, a all, i invert, Enter confirm.
--select for scripts and CIPick rows by number: --select=1,3,5-7. Interactive mode prints the equivalent value so you can replay the same choice later.
Requests that share path and method are marked skip, with a hint telling you how to keep the one you want.
mocks for MSW, Playwright and mock servers, chrome-overrides for Chrome DevTools Local Overrides.
File not found, File is not valid JSON, File is not a valid HAR file. Unparsable URLs are skipped with a warning, not a crash.
TypeScript, ES modules, bundled with esbuild into a single small install. Runs on Node.js 22 or newer.
--format=mocks (default)Layout is <output>/<url path>/<METHOD>.json. Each file is the raw response body, nothing else: no headers, no status codes. This is the layout mocks-to-msw and mocks-to-playwright consume and connect-api-mocker (Express / webpack-dev-server middleware) serves.
import { createMockHandler } from "mocks-to-msw";
import mocks from "./mocks/mocks";
const { mock } = createMockHandler<keyof typeof mocks>({ mocks, debug: true });
export const handlers = [
mock.get("/client"),
mock.post("/client/application", (data) => ({ ...data, modified: true })),
];
mocks-to-msw adds type-safe URL/method pairing, async loading, response modifiers, debug logging, origin configuration, and a CLI that generates a typed import file from the mocks folder.
import { createMockRoutes } from "mocks-to-playwright";
import mocks from "./mocks/mocks";
const { mock } = createMockRoutes<keyof typeof mocks>({ mocks });
test("shows the client", async ({ page }) => {
await mock.get("/client")(page);
await mock.post("/client/application", (data) => ({ ...data, status: "approved" }))(page);
await page.goto("/");
});
mocks-to-playwright serves the same mocks through page.route() with the same typed API, works on a page or a whole browser context, and reads the same generated mocks.ts.
--format=chrome-overridesFiles are named the way Chrome names them: <host>/<path>, query string kept in the file name, index.html for paths ending in /, special characters escaped, very long URLs in a longurls folder. Binary responses (base64 in the HAR) are decoded, so images and fonts are written as original bytes.
In Chrome: Sources → Overrides → Select folder for overrides, pick exactly the folder you wrote to, allow access, reload. Chrome now serves those responses instead of the network, with no code changes to the app at all.
/api/users and /api/users/1 conflict, and the CLI reports A file and a folder would have the same path.The API is not ready, down, or behind a VPN. Record the app once against staging, generate mocks, keep building offline.
npx har-to-mocks ./staging.har ./src/mocks/api --url=/api --dry-run
# then the same command without --dry-runStories need realistic data. Generate mocks, wire them with mocks-to-msw, reuse the same handlers in the app and in Storybook. The Medium article covers this flow ↗
npx har-to-mocks ./file.har ./mocks --url=/api
Fixtures nobody updates. Deterministic responses from real traffic instead, served by MSW in Vitest, Jest, React Testing Library or Cypress, and by mocks-to-playwright in Playwright, all from one mocks.ts.
npx har-to-mocks ./file.har ./mocks --url=/api --method=GET --method=POST
QA attaches a HAR to the ticket. Run interactive mode, preview the responses, pick the failing call, replay it.
npx har-to-mocks ./ticket-4821.har ./mocks --interactive
Replace any production response with a saved or edited one. Write an overrides folder, select it in DevTools. No proxy, no code change.
npx har-to-mocks ./prod.har ./overrides --format=chrome-overrides
Day one, no backend access. Record the running app, generate mocks, and have a fully working local frontend before you understand the backend.
npx har-to-mocks ./day-one.har ./src/mocks --url=/api --type=xhr --type=fetch --dry-run
Freeze a known-good data set once so demos never depend on a live service.
npx har-to-mocks ./golden-demo.har ./demo/mocks --url=/api
Designers and PMs see the UI with real data on a laptop with no backend access.
npx har-to-mocks ./app.har ./overrides --format=chrome-overrides
Install the har-extraction skill and ask Claude Code: "Extract mocks from this HAR file for my API tests." Non-interactive flags, deterministic output, dry run and readable tables make the CLI agent-friendly.
npx skills add peterknezek/skills
?page=1 and ?page=2 hit the same path. The Query column plus --select or interactive mode let you keep the one you mean; chrome-overrides keeps both as separate files.
npx har-to-mocks ./file.har ./mocks --url=?page= --select=2
None of these tools are bad. har-to-mocks is simpler for one specific job: "I want JSON files from real traffic."
| Alternative | What it does | Why har-to-mocks is different |
|---|---|---|
Playwright routeFromHAR | Replays a HAR inside Playwright tests | One HAR blob per test suite, hard to read or edit for a single test. har-to-mocks produces one JSON file per endpoint; mocks-to-playwright serves them in Playwright with typed routes and per-test modifiers, and the same files work in MSW, Storybook, Chrome and any mock server. |
| Hand-written MSW handlers / fixtures | Full control | Slow, error-prone, drifts from the real API. har-to-mocks generates the data; you still write handlers if you want, or let mocks-to-msw do it. |
har-to-stubby, MockServer HAR import, har-mock-server, @jmcorp/har2mocks | Convert HAR to a specific server's format or run a replay server | Tool-specific or server-bound. har-to-mocks is a files-first, tool-agnostic generator with preview, dry run, interactive picking, duplicate detection, and a Chrome DevTools format. |
| Chrome DevTools "Override content" by hand | Edit one response at a time inside DevTools | Manual per request. har-to-mocks writes the whole override folder from a recording in one command. |
@oclif/core v5, @inquirer/prompts, ESLint + Prettier.--select, friendly errors, security dependency bumps. Node.js ≥ 18."Hi, I am currently really liking how easy it is to get json responses from the HAR network traffic file."
"Hi again, this tool has been very helpful." … "Thanks again for all the support."
Starred and forked by a small group of developers, and adapted by others (for example huihao/har-to-msw-mocks). Good first issues welcome.
skills.sh, playbooks.com and tomevault.io list the author's har-extraction skill, describing the pipeline as HAR File → har-to-mocks → JSON Mocks → mocks-to-msw → MSW Handlers → Storybook/Tests.
Used it? Share your use case in the GitHub discussion or post on X and tag @peter_knezek. Real quotes will replace this box over time.
Join the discussionNot silently. Without an output folder nothing is written. With one, the Status column tells you what will be created, updated or skipped, --dry-run shows the full tree first, and interactive mode asks for confirmation.
Narrow it with --url, --method and --type, then pick rows with the interactive picker or --select=1,3,5-7.
Requests are keyed by URL path and method, so multiple GraphQL operations on one endpoint collide today (open issue #12). Interactive mode and --select let you pick which one to keep. Operation splitting is not implemented.
The Query column shows them apart. The chrome-overrides format writes separate files per query string; in the mocks format use --select or interactive mode to choose. Automatic handling is tracked in open issue #18.
The default resource type is xhr and the default method is GET. Pass --type=fetch (and --method=POST etc.) to include them. --url is a case-sensitive substring match, not a regex.
HAR files can contain cookies and tokens. The mocks keep response bodies only, no headers. Still, review the output before committing it.
Yes. mocks-to-playwright ↗ registers them with page.route(): await mock.get("/client")(page). It uses the same mocks.ts as mocks-to-msw, so one set of mocks feeds Storybook, the app and your end-to-end tests.
Full CLI reference, every feature with its real output, the HAR export guide for Chrome, Firefox and Safari, FAQ, and the changelog.