Brie is an open-source browser extension that captures screenshots, console errors, network issues, and user actions into a single shareable bug report, and it is built for the developers who fix bugs as much as for the testers, QA staff, and support teams who report them.

What it is

Brie lives in the browser extension ecosystem and is written in TypeScript. The repository is a Turborepo monorepo built on React, Vite, and Tailwind CSS, and it ships as an extension a user adds to their browser, pins to the toolbar, and clicks when something goes wrong. Instead of asking a reporter to describe a failure in prose, the extension records the state of the page at the moment of the bug.

The concrete problem it solves is the low-quality bug report. Brie replaces the back-and-forth emails and messy, context-free screenshots that normally travel between the person who hit the bug and the person who has to fix it. When a capture is taken, the extension automatically gathers console logs, network errors, and the sequence of user actions that led to the failure, then produces a report link that carries that full context. The recipient opens one link and sees what happened rather than reconstructing it from a thread.

Key capabilities

• Captures an annotated screenshot when the Brie toolbar icon is clicked, with annotation available before the report is sent.
• Auto-captures console logs, network errors, and user actions alongside the screenshot, so a report carries reproduction context rather than a picture alone.
• Generates a report link that can be shared over email, Slack, or any other platform the reporter already uses.
• Ships as a Turborepo monorepo written in TypeScript, with React and Tailwind CSS in the extension stack.
• Carries translation files in packages/i18n/locales, with the README available in fourteen languages including Spanish, French, German, Japanese, Korean, Chinese, Arabic, and Hindi.
• Publishes a contributing path through the good first issue label on GitHub, a docs/CONTRIBUTING.md guide, and a docs folder.
• Is licensed under Apache-2.0.

Who uses it and how

• QA and manual testers working through a web application who need each failure to arrive with logs and steps already attached.
• Support and customer-facing teams who field user complaints and currently relay them to engineering by hand.
• Development teams triaging a queue of reports, where the console and network data captured at report time shortens the distance between report and fix.
• Contributors to the project, who work inside the Turborepo monorepo and can start from labelled good first issues or from adding a new locale to packages/i18n/locales and docs/readme.
• Distributed or multilingual teams, since the extension and its documentation carry locale files for fourteen languages and accept new ones by pull request.

Getting started

Installation is through the website at https://go.brie.io/lp, after which the extension is added to the browser and pinned to the toolbar for quick access. Capturing starts by clicking the Brie icon; the README documents no package install, Docker image, or compose file.

How it compares

No paid products or comparable tools are named in the facts for this entry, so Brie stands alone in this registry on the evidence available. What the facts do establish is a permissively licensed Apache-2.0 codebase with a public repository, a public issue tracker, and an open contribution path, alongside a hosted service that produces the report links the extension shares.

When to use it — and when not to

Brie suits teams that want richer bug reports without building capture tooling themselves, and it is genuinely open source for anyone who wants to read, fork, or contribute to the extension. A self-hoster should note that the README documents no self-hosting or deployment route: reports are shared as generated links, and the documentation covers the extension and contributing rather than operating a backend. Teams whose data policies forbid sending page captures and console output through a hosted report link should treat that as a blocker, and anyone expecting a large, actively reviewed codebase should weigh the twenty-five open issues against the small maintainer team listed in the README.