Back
Web DevelopmentTools

Mockingbird: the Chrome extension I built to mock APIs from the browser

It is now live on the Chrome Web Store

Over the last few weeks I have been working on Mockingbird, a Chrome extension for frontend developers that lets you mock API responses directly from the browser.

The idea came from a very common annoyance: you are building a screen, you need to test what happens when the backend returns a 500, a session expires, a request takes too long, or the network fails, and you end up changing temporary code, running a mock server, or asking backend to force a specific case.

Mockingbird removes that friction. It intercepts the calls your app makes and answers them itself, with no proxy, no extra backend, and no changes to a single line of your code.

Mockingbird official page on the Chrome Web Store

You can install it from the official Mockingbird page on the Chrome Web Store.

Why I wanted to build it

There are many tools for mocking APIs, but I kept running into the same problem: they changed the response body while leaving the HTTP status as 200.

That looks good enough until you need to test real error handling. If your frontend receives a 200, response.ok is still true, Axios does not enter the catch, Angular does not emit an HttpErrorResponse, and your error UI never runs the way it would in production.

What I wanted was simpler and more honest: if I configure a 500, I want it to be a real 500.

That is why Mockingbird returns real HTTP status codes:

  • fetch resolves with response.ok === false and response.status === 500.
  • XMLHttpRequest ends with xhr.status === 500.
  • axios rejects with error.response.status === 500.
  • Angular HttpClient emits an HttpErrorResponse with the correct status.

That detail changes the way you test an interface, because the error path finally runs the same way it would against a real API.

It also simulates network failures

An HTTP error is not the same as a network failure.

A 500 means the request reached the server and the server responded with an error. A network failure means the request never arrived, the user is offline, or the browser could not complete the connection.

Mockingbird lets you simulate both cases. When you configure a network failure, fetch rejects with a TypeError, XHR fires error with status 0, and Axios lands in the catch without error.response.

That matters when testing offline screens, retries, lost connection messages, and states that often remain untested until they show up in production.

Scenarios, delays, and reusable rules

The extension is built around rules. Each rule defines which URL should be intercepted, what response should be returned, which HTTP status to use, and whether a delay should be applied.

Those rules can then be grouped into scenarios. For example:

  • Backend down: several APIs respond with 500.
  • Expired login: protected endpoints return 401.
  • Slow connection: responses arrive after a few seconds.
  • Happy path: everything responds correctly, without depending on the real backend.

You can enable several scenarios at the same time. Their rules add up and the first match wins, so it is easy to build combinations that let you test a screen under conditions that feel closer to reality.

It also includes glob patterns or regular expressions, a built-in tester to check whether a URL matches, a Chrome side panel editor, a log of intercepted responses, and JSON import/export so you can share setups with your team.

Everything runs locally in your browser. Mockingbird does not send your data to any server.

I wanted the icon to be simple, recognizable, and connected to the name. A mockingbird is known for imitating sounds. The metaphor fit nicely: the extension imitates API responses so you can build and test your frontend without depending on everything else being ready.

Mockingbird logo

The result is a purple icon, direct and minimal, designed to work well both in the extensions toolbar and on the Chrome Web Store.

I let August pass to see if people used it

Publishing a small tool always leaves one question open: will anyone use it besides me?

That is why I decided to let August pass before writing this post. I did not want to announce it on the same day I published it and only ride the launch excitement. I preferred to wait a month, look at the numbers, and check whether there were real signs of usage.

The answer has been positive: over the last 30 days, Mockingbird has reached 42 installations.

Mockingbird installations over the last 30 days

It is not a huge number, but for a new extension, with no campaign, built as a developer tool, and published from scratch, it feels like a very good signal. Good enough to keep polishing it and share it with more people.

If you build frontend, give it a try

Mockingbird is built for those moments when you need to understand how your product behaves when the backend does not respond the way you expect.

If you work on forms, dashboards, login flows, payments, offline screens, loading states, or any interface that depends on an API, it can save you a good amount of time.

You can download it here:

Install Mockingbird from the Chrome Web Store

If you try it and find something that could be better, I would love to hear your feedback. The extension is already published, but the interesting part starts now: turning it into an increasingly useful tool for people who build frontend every day.