Product
How BugBundler works
One click turns "it's broken" into a complete, reproducible bug report. The whole thing takes under a minute, and the finished report is written to the reporter's own device as a single HTML file. BugBundler does not host report content: you share the file yourself, or send it straight to your own Jira.
- One click to capture
- One file to hand over
- Nothing hosted by us at any step
Watch it end to end
Capture, annotate, export, attach — the whole loop in under a minute.
1. Capture
Click the toolbar icon on the page where the bug happened. Choose a full-page capture or drag to select an area. In that single action BugBundler collects:
- The screenshot, full page or selected region.
- Console logs, including errors and warnings.
- Network activity, including failed requests and status codes.
- A DOM snapshot of the rendered page exactly as it was at the moment of capture.
- Performance metrics: LCP and CLS via PerformanceObserver, plus navigation timing.
- URL, viewport size, browser and operating system.
The reporter does not open developer tools, and does not need to know what any of it means. That is the point: a tester's job is to find bugs, not to learn a tool built for developers.
2. Sensitive fields are redacted before anything is written
This happens automatically, as part of the capture, not as an extra step someone has to remember. The following are blurred in the screenshot and stripped from the DOM snapshot:
- Password inputs.
- Card number, security code and expiry fields, detected by their autocomplete attributes.
-
Fields whose name contains
card,credit,cvv,cvcorssn. -
Anything you mark yourself with a
data-redactattribute, plus any custom CSS selectors you configure.
The screenshot path and the DOM snapshot path share one definition of what counts as sensitive, so a field that is blurred in the image can never leak its raw value in the markup underneath.
3. Annotate and describe
Mark up the screenshot with arrows, freehand pen, boxes, circles and text in a handful of colours, so the developer's eye lands in the right place immediately.
The description field opens on a reproduction template rather than an empty box: steps to reproduce, expected behaviour, actual behaviour, notes. An empty box is what produces "it doesn't work"; a template is what produces something a developer can act on. You can add custom fields if your team needs a specific one filled in every time.
4. What the report actually is
One HTML file. Not a link, not a record in someone's database. It opens in any browser, needs no viewer application, and requires no account to read, so a developer who has never heard of BugBundler can open it and get to work.
Opened from disk it is fully interactive: tabs for the screenshot, console, network and DOM, with filters for log level and request status so a developer can go straight to the failed calls. The DOM snapshot can be downloaded separately as its own HTML file.
5. Optional encryption
If the capture is sensitive enough that you do not want it readable by anyone who happens to receive the file, export it encrypted with a password. The file is encrypted with AES-GCM 256, with the key derived from your password using PBKDF2 over SHA-256 at 100,000 iterations.
The exported file decrypts itself: the recipient opens it in a normal browser and enters the password. There is no plugin and no service in the middle, so send the password by a different channel than the file itself.
6. Send it to Jira, or share the file yourself
If an owner or admin has connected your Jira site, the report can be filed as an issue from the capture panel itself. The annotated screenshot and the complete HTML report are attached to that issue, the destination project is picked automatically from the URL the report was captured on, and the issue is attributed to whoever filed it. That send is opt-in and per report: it passes through our EU infrastructure in Finland only in order to reach your own Jira site, and is never written to our database, our file storage or our logs.
Otherwise, share the file yourself — attach it to a GitHub issue, drop it in a chat, or send it by email, exactly as you would share any other file. On that path nothing reaches us at all, and it works with no network connection. See the Jira workflow or the GitHub one.
7. Setting up a team
Using the extension requires a workspace account for licensing. Sign in with email and password or with Microsoft SSO, then invite colleagues by email. Members hold one of three roles, owner, admin or member, and seats can be added or reduced as the team changes.
That account layer holds name, email, company, role and subscription detail only. It never holds report content, and it is hosted in the EU on Google Cloud: Cloud Functions in Finland, database in Stockholm, Sweden. The compliance page lists every subprocessor, and a Data Processing Agreement is available on request.
8. Nothing to unlock
Every feature is included at every seat tier. There is no plan to upgrade into for console capture, redaction, encryption or EU hosting, and the only thing that changes with volume is the per-seat price. Pricing is $27 to $29 per seat per month with a five-seat minimum, and every plan starts with a 30-day free trial, no credit card required. See pricing for the tiers.
Try the whole loop
The fastest way to understand it is one real bug
Install the extension, capture something broken in your own environment, and open the file it writes. Every step above takes about a minute end to end.