A BugHerd alternative that finds the source file.

What Zidl does that BugHerd cannot

Zidl loads inside your app from a script tag rather than acting on the page from outside. Same-origin access is what makes all three of these possible at all.

• The source file. Zidl walks the React fiber to name the component, file, line and column behind the element, and turns it into an editor deep link. See source detection.
• A repro that runs. The steps that led to the bug export as a Playwright test rather than being described in a comment. See the step recorder.
• Annotations over the live DOM. Marks are vector data rendered on the real product, so a report does not go stale against a UI that has since moved.

Why the difference is architectural

This is not a feature BugHerd has not got around to. A feedback widget that attaches to any site has to treat the page as a finished document — it can see the DOM, the CSS selector and the pixels, and that is genuinely all there is to see from outside.

The component that rendered a button is not in the DOM. It exists in React's fiber tree, in memory, reachable only by code running on the same origin inside the app. Zidl asks for a script tag precisely so it can stand in that position. The cost is that you have to add the tag, and that the debug data it reads only exists in a development or staging build. The return is the file path.

What the developer actually receives

The clearest way to compare the two is to look at what lands on the other end of the same click. From BugHerd: a pin on an element, the reporter's sentence, a screenshot, and the browser, OS and viewport it happened on. From Zidl:

BUG-014  ·  high  ·  bug
"Place order" overflows its container at 375px

source   src/components/Checkout.tsx:87:11
route    /checkout?tab,id
surface  modal
steps    4 recorded  →  checkout.spec.ts

The difference is not thoroughness — BugHerd's metadata is real and useful. It is who does the next piece of work. With a pin and a screenshot, the developer opens the app, finds the screen, works out which component renders that element, and reconstructs how the reporter got there. With the block above, that work has already happened, and the last line is a test that will keep failing until the bug is genuinely fixed.

Side by side

Where BugHerd is the better choice

BugHerd is built for agency-to-client feedback, and on that job it beats Zidl outright. A client clicks part of the page, the comment attaches to that element with a screenshot and browser details behind it, and reporters need no account — which matters enormously when the reporter is a client who will use the tool four times and never log in again.

It is also framework-agnostic and needs nothing from your build, so it works on a WordPress site, a Webflow site, a Rails app, or a production site you do not control the deploys for. Zidl works on none of those: it wants React, and it wants a development or staging build, because that is where the debug data it reads exists.

If your reporters are clients rather than colleagues, or your app is not React, stop here — BugHerd is the right tool and Zidl will not serve you.

Moving over

There is no import and no migration proper, because the two tools hold different things. What works is running them alongside each other for one sprint.

• Add the tag to staging only, naming staging in data-hosts. Production is untouched, so nothing you ship changes. See the docs.
• Invite the people who file the most bugs. Reporters need an account, which is the real change in habit — budget for that rather than for the install.
• Leave existing BugHerd reports where they are. Closing out a backlog in two places is worse than letting the old one drain.
• After a sprint, compare how long the average report took to act on. That is the only number that decides this.

Zidl is free for every team while we are in beta — see pricing. If it does not work out, delete the script tag and every trace of it is gone from your app.

Questions people ask when switching

Does Zidl work on our production site?

It is off in production by default, and deliberately. The tag names the hosts it may run on, so the same markup is safe to ship everywhere and simply stays dormant in production. It also would not help there: the component and file names it reads are stripped out of a production build. BugHerd has no such constraint — see the developer notes.

Does it work with Vue, Angular or plain HTML?

Source detection reads React's fiber tree, so the file-and-line resolution is React-only. On a non-React app the headline feature simply is not there, and BugHerd is the better tool. See source detection for what it needs from your build.

Do reporters need an account?

Yes. Members join a team by email-matched invite and hold one of four roles. That is a genuine step backwards from BugHerd's guest reporting, and it is the right trade only when your reporters are colleagues who file bugs every week rather than clients who file four and leave.