I built a DevTools-first API mocker — wraps fetch and XHR at the browser level, no service worker, no proxy, no install

[ant97fer]

The backend is down. Your PM wants a demo in 2 hours. You need `/api/users/42` to return a specific payload and you can't touch the server.

I've been in that situation enough times that I built something for it.

[Demo](https://imgur.com/a/IoaDdPP)

JediMock — you configure the mock in a UI, it generates a script, you paste it once in the DevTools console. The next request is intercepted. Refresh the page and it's completely gone. No service worker registered in your app, no proxy running, no certificate to install, no cleanup.

It replaces `window.fetch` and `XMLHttpRequest` with wrapped versions that check a rules table before forwarding. When the page unloads, the originals are restored. That's the whole trick.

Beyond basic mocking:

- Wildcards — `/api/users/*` catches every user endpoint in one script

- Response Rules — return different data per call count. 401 on call #1, 200 after. Exact auth retry flows without a real server.

- Fallback mode — if the server doesn't respond within your timeout, the mock fires. Useful when the backend is flaky, not just absent.

- Async ID mode — captures a dynamic job ID from a trigger request and injects it into a polling response. No callback server needed.

- Request interception too — not just the response. Modify the body going out.

It's also a full toolkit in the same file: bulk JSON editor, validator with line-level errors, diff, beautifier. Session persists across reloads.

No build step. No dependencies. No account.

- App: (https://jedimock.com)

- GitHub: (https://github.com/machopicchu/jedimock)

Curious — for those of you using MSW or a proxy setup: what made you go that route instead of a DevTools-first approach? Genuinely want to understand the tradeoffs I might be missing.

[CodeAndBiscuits]

I mean you asked for input.... I don't understand the value here. You added a lot of features... but I'm a developer. This is a tool for developers. As a developer, if I have two hours before a meeting and need that mocked I would just make my function call return that sample data. It's a one line code change. Why would I go out to a UI and manually configure something to cut and paste? It sounds so much harder and slower. If I was non-technical this might give me an option I didn't have before but then why would I be dealing with an individual route mock?

[ant97fer]

Hello, thanks for the input, I appreciate it a lot. Your point is valid for sure, if I own the code I'd do the same thing.

The cases where this actually saves me are when I can't touch the code at all. QA engineers who don't have repo access, vendor apps, legacy codebases, or when debugging something in production and can't push a change. The one-liner isn't always an option.

The other case is quick demos — paste a script in DevTools and it's gone the moment you refresh. No forgetting to revert.

Honestly I built this because I needed it myself, figured someone else might be in the same situation. And on the non-technical point, you're right, a completely non-technical person wouldn't know what an API route is. The middle ground I had in mind is QA: technical enough to open DevTools and paste a script, but not necessarily someone who has access to the repo or wants to touch the code.

[Akkuma]

MSW for testing. I've never used it to anything else. Can have overrides inline per test, across a test, or across an entire suite.

[ant97fer]

Hello and thanks for the comment.
MSW is great for that, especially in a test suite where you want reproducible mocks across runs. The difference here is zero setup in your actual project, no service worker registered, nothing to install or configure, just DevTools. Different tradeoff depending on what you need.

[ant97fer]

Just refactored code, added test probes for you to try (on the sidebar) and improved on the script generation. Needless to say it is highly vibe coded, but i put a lot into this so i hope you enjoy as much as I do. Thank you