compare · marker.io
A Marker.io alternative that sends code, not a video.
Zidl answers “where is it?” with a file and line, and “how do I get there?” with a test that runs. Marker.io answers both with something a developer has to watch and then transcribe.
Two answers to the same question
Both tools set out to capture "what was the state when it broke". They hand the developer very different artifacts.
| The question | Two answers |
|---|---|
| Where is it? | Zidl: the component, file, line and column, as an editor deep link. Marker.io: an annotated screenshot of the region. |
| How do I get there? | Zidl: a Playwright test to run. Marker.io: a session replay to watch. |
| What broke? | Marker.io: console logs and network context. Zidl does not capture console output. |
| Where does it go next? | Marker.io: two-way sync into Jira, Linear and Asana today. Zidl: its own board, with those integrations in build. |
A replay is evidence. A test is work already done.
This is the whole argument, so it is worth being precise about it. A session replay is genuinely good evidence — better than a screenshot, and much better than a sentence. The question is what happens to it.
A replay is watched once. The developer scrubs to the moment it broke, works out what the reporter did, and then re-does it by hand in their own browser to get to the same state. Then, if the team is disciplined, someone writes a regression test describing those steps. The replay itself does not survive the fix — it is deleted with the ticket.
A generated test skips the middle of that. The steps arrive as code using role, test-id and label locators, so the developer runs one command to land in the broken state, and the same file goes into the suite afterwards. It keeps failing until the bug is genuinely fixed, and it keeps passing for years afterwards — which is the part a replay can never do.
await page.getByRole('link', { name: 'Cart' }).click()
await page.getByTestId('qty-4242').fill('3')
await page.getByLabel('Card number').fill('4242 4242 4242 4242')
await page.getByRole('button', { name: 'Place order' }).click()That is the artifact, not a description of one. See the step recorder for how the buffer is recorded and trimmed on the way out.
Side by side
| Marker.io → Zidl | |
|---|---|
| Source file, line and component | Zidl only |
| Repro exported as a runnable test | Zidl only |
| Opens the element in your editor | Zidl only |
| Annotations over the live DOM | Zidl only |
| Pins to an element | Both |
| Severity, labels, assignees | Both |
| Annotated screenshot | Marker.io captures this |
| Console logs and network context | Marker.io captures this |
| Session replay | Marker.io only |
| Two-way sync with Jira, Linear, Asana | Marker.io today |
| Guest reporters without an account | Marker.io |
| Any framework, any environment | Marker.io |
Where Marker.io is the better choice
Marker.io is the most technically thorough of the widget-based tools, and two of its strengths are ones Zidl has no answer to at all.
- Console and network context. Zidl captures neither. If your bugs are usually a failed request or an exception rather than something visibly wrong on the screen, Marker.io is reading the layer where your problem lives and Zidl is not.
- The hand-off. Two-way sync pushes reports into Jira, Linear and Asana today, and updates flow back. Zidl's own integrations are in build rather than shipped, so for now a report leaves the board by hand — see Zidl with Jira and Slack.
If the hand-off into your tracker is the whole reason you are buying a tool, that is the case for Marker.io right now, and it is a fair one.
Moving over
Run both for a sprint rather than switching. They capture different layers, and you want to find out which layer your bugs actually live in.
- Add the tag to staging, naming staging in
data-hosts. Nothing about your production build changes. - Keep Marker.io pointed wherever it is now. Nothing about this is exclusive.
- At the end of the sprint, sort the reports by how they were resolved. Count how many needed a console log, and how many needed to know which component it was. That ratio is your answer.
Questions people ask when switching
Does Zidl capture console errors?
No. It captures the element, the source location, the route and the steps — not console output or network requests. If a typical bug on your team is diagnosed from a stack trace rather than from looking at the screen, Marker.io is reading the layer you need and Zidl is not.
Can Zidl push reports into Jira today?
Not yet. Jira, Asana and Slack integrations are in build; today a report leaves the Zidl board by hand. Marker.io's two-way sync is shipped and working, and if that is the deciding feature you should weight it heavily. See Zidl with Jira and Slack.
Do we need Playwright set up to use the export?
To run the exported spec, yes — it is an ordinary Playwright test file. To read it, no, and that alone is often enough: the locators name the elements the reporter touched, in order, which is the reconstruction step a developer would otherwise do by hand.
Pick Zidl when the reports are internal, the app is React, and what you want on the other end is a file path and a failing test rather than a video and a paragraph. It is free during beta — see pricing — and the docs cover what installing it involves.