PocketMocker intercepts HTTP inside the page so you can rewrite API responses without a mock server

What the tool does, in one sentence

PocketMocker is an in-page HTTP controller for frontend development, and the README states plainly what that means in practical terms: it lets you decide what your API responses should be without touching the backend or setting up a mock server.

The implementation is a visual control panel directly in your browser to intercept, override and manipulate HTTP responses, helping you build UIs that handle failure by seeing changes instantly.

That last clause is the design decision. The interception happens in the page, so the response you change is the response the running UI consumes, and the update is visible without a reload, a rebuild or a switch to another tool. Nothing is proxied and no separate process is listening on a port.

The project's own summary of why it exists is organised around three headings. Mock with less effort, which means intercepting requests automatically, generating smart data and importing API docs with one click. Control completely, which splits into timing to simulate network latency and race conditions, status to force 500 errors, 401 unauthorized and empty responses, and payload to test edge cases and exception scenarios. And debug instantly, editing responses directly in the browser and seeing UI updates with no tool switching.

The package is on npm as pocket-mocker, the live demo is at tianchangnorth.github.io/pocket-mocker/, and the user manual is at docs/USER_MANUAL.md with a Chinese counterpart at docs/USER_MANUAL.zh-CN.md.

Installing it and the zero-configuration start

The install is a dev dependency, and the README gives three package managers.

npm install pocket-mocker --save-dev
# or
yarn add pocket-mocker -D
# or
pnpm add pocket-mocker -D

The zero-configuration mode is a single import in your entry file, guarded by an environment check.

import { pocketMock } from 'pocket-mocker';

// Only start in development environment
if (process.env.NODE_ENV === 'development') {
  pocketMock();
}

After starting your project, a PocketMock floating panel appears in the bottom-right corner of the page.

The environment guard is not decoration. The tool patches request handling inside the page, so shipping it to production would mean your users' API responses are being rewritten by your own bundle. The check is the only thing standing between the library and your users, and it is the developer's responsibility to keep it in place.

The second method is the one the README recommends, and it exists for a reason that the first method cannot solve: in local mode, the rules live in the browser, so they are not shared.

The Vite plugin, and why team mode is different

The team collaboration mode adds a Vite plugin that integrates with the file system, saving mock rules to config files for team sharing.

import { defineConfig } from 'vite';
import pocketMockPlugin from 'pocket-mocker/vite-plugin';

export default defineConfig({
  plugins: [
    pocketMockPlugin()
  ]
});

With the plugin in place, PocketMock automatically detects the plugin environment and switches to Server Mode, which is the mechanism by which the rules get written to disk rather than held in the page.

That distinction is the whole point of the two modes. In local mode you get the fastest loop, an import and a floating panel, with rules that live as long as the browser tab. In server mode the rules become files, which means they can be committed, reviewed and shared, so a designer and a developer can point at the same mock definition.

The package.json shows how the plugin is published. The main export points at the built bundle with both a UMD build at ./dist/pocket-mock.umd.js and an ES build at ./dist/pocket-mock.es.js, and there is a separate ./vite-plugin export path with its own type declaration, which means the plugin ships as its own entry point rather than being pulled into the main bundle.

The rest of the toolchain is a Svelte and Vite setup, with svelte-check for type checking, vitest for tests, and a separate vite.demo.config.ts for the published demo build, which is deployed with gh-pages.

URL pattern matching, and how you get at the captured values

The URL matching is more than a prefix string, and the patterns are worth writing down.

Path parameters look like /api/users/:id, which matches /api/users/123 and /api/users/john. Wildcards like /api/* match /api/users, /api/users/123 and /api/users/123/posts. And mixed patterns like /api/:version/users/*/profile match /api/v1/users/123/profile.

When a mock is a function rather than a static payload, the captured parameters and the query string are available on the request.

(req) => {
  const { id, version } = req.params;
  const { include } = req.query;
  return { id: parseInt(id), version, includeAuthor: include === 'true' };
}

So a dynamic mock can vary its output based on the URL, and the params object carries the named captures while query holds the parsed query string. The `include` example shows the pattern of treating a query flag as a boolean, which is a common shape for an API that takes an include flag.

The pattern syntax is the same vocabulary Express and most router libraries use, which means the rules read the way a developer already expects rather than requiring a new mental model.

The smart mock generator and its template syntax

The Smart Mock Generator creates realistic test data with simple template syntax, and the README's example is the clearest reference.

{
  "user": {                           // → Generate user data
    "id": "@guid",                   // → "550e8400-e29b-41d4-a716-446655440000"
    "name": "@name",                 // → "John"
    "username": "@username",       // → "brightpanda"
    "email": "@email",               // → "[email protected]"
    "avatar": "@image(100x100)",     // → "https://via.placeholder.com/100x100"
    "age": "@integer(18,60)",       // → 25
    "role": "@pick(admin,user)",     // → "admin"
    "ip": "@ip",                  // → "192.168.1.1"
    "ipv6": "@ip(v6)"                // → "2001:0db8:85a3:0000:0000:8a2e:0370:7334"
  }
}

The generator table lists the common ones. @guid gives a unique ID, @name a random name, @username a random username, @email an email address, @ip a random IP in v4 or v6, @integer(min,max) a random integer, @pick(A,B,C) a random choice and @image(100x100) a placeholder image.

The longer list adds @float(min,max,decimals), @boolean, @string(length), @username(separator, randomDigits, maxLength, dictType) with its own parameters, and @phone(countryCode).

The value of this is not realism for its own sake. A UI that renders a name is a different UI from one that renders a 200-character name with characters outside the Latin range, and @string(length) plus the Unicode-capable generators are how you find the layout bugs without hand-writing an edge case fixture. The generator syntax is also why the generator can be a documented, reviewable format rather than a pile of fixture files.

The use cases, which are really a state matrix

The README frames the value as a set of states you can switch between quickly.

Instant state switching means toggling between Success, Error with 500 or 404, and Empty Data states in one click, to verify how your UI handles loading spinners or error toasts without changing a single line of code.

On-the-fly data tweaking is editing the response JSON directly in the panel, for a long username, a missing avatar or a specific price format, and seeing the UI update instantly.

Edge case verification is simulating network delays, timeouts or unauthorized 401 responses to check that the application handles exceptions gracefully.

Read together, these describe a matrix of states a real API can be in, and the useful observation is that most of that matrix is tedious to reproduce properly. Forcing a 500 is easy in a panel and awkward with a real backend, because you need a code path that returns one. Simulating latency is easy in a panel and genuinely awkward to reproduce on a real network.

The one usage that carries the most risk is the latency simulation, because it changes how the page behaves rather than only what it displays. If the UI has a race between a response arriving and a user action, that race is exactly what you want to exercise, and it is the kind of bug that never appears on a fast local network.

Where PocketMocker is the wrong choice

Four cases argue against it.

The first is a shared mock server for a whole team. The local mode keeps rules in the browser, and even the Vite plugin ties the rules to one project's config rather than to a service the frontend, the backend tests and the CI all share. If your team wants one mock definition used by three consumers, a dedicated mock server is the better shape.

The second is backend contract testing. PocketMocker intercepts what the browser sends and does not validate the request against the API schema. It lets you invent responses freely, which is perfect for UI work and useless for checking that your client and your server agree.

The third is anything outside the browser. Because the interception is in the page, it does not affect Node-side fetches, service workers running in a different context, or a mobile client hitting the same API. If your testing needs to cover a native app or a server-side renderer, this does not reach it.

The alternative in the same direction is a proxy-based mock tool such as a dedicated interception proxy, or a mock server with a route definition file. The difference in approach is where the trust boundary sits. PocketMocker sits inside your application, so it needs no ports, no configuration of the backend URL and no separate process, and it sees exactly the requests your code makes including their headers and body. A proxy sits between and sees the same requests but needs a setup step and a port, and it also captures traffic from tools other than the browser. If your goal is a fast inner loop while building one screen, the in-page approach wins. If your goal is a shared, reviewable definition of the API, a checked-in mock server wins.

Editorial conclusion

PocketMocker fits a frontend developer who wants to inspect and rewrite API responses live in the browser rather than maintaining a separate mock server, since the floating panel sits in the same page as the UI you are debugging. It does not fit a team that needs a shared, checked-in mock backend, since the local mode keeps its rules in the browser and only the Vite plugin writes them to files. Install it with `npm install pocket-mocker --save-dev`, start it behind a `process.env.NODE_ENV === 'development'` check, and add the Vite plugin when you want the rules in version control for the rest of the team.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tianchangNorth/pocket-mocker on GitHub