How is this different from a normal screenshot tool?

A screenshot tool gives you images. Trace gives you a document. Every capture gets a heading and a description, pages are ordered and numbered, and the export has a cover page and footer — so what you hand over reads like documentation rather than an attachment dump.

How do I convert screenshots to PDF?

Capture or import your screenshots, add a heading and description to each one in the Report Editor, then hit Generate PDF. Trace lays them out as numbered pages with a cover, so the screenshot-to-PDF conversion happens in the same window you captured them in — no separate converter needed.

How do I combine multiple screenshots into one PDF?

Every screenshot you capture or upload lands in the same queue. Drag them into the order you want in the Report Editor sidebar, then export — Trace combines them into a single multi-page PDF with consistent headings, numbering and footers.

Can I annotate screenshots before exporting them to PDF?

Yes. Open any capture in the built-in editor and mark it up with arrows, boxes, highlights, blur, numbered steps or freehand drawing before it goes into the report. Annotations are baked into the exported PDF, not added separately.

Is Trace a screenshot annotation tool?

It includes one — arrows, text, highlights, blur and more — but annotation is only half of it. Trace also organizes annotated screenshots into a structured PDF report with headings, descriptions, a cover page and page numbers, so you get documentation, not just a marked-up image.

Can I create a bug report from screenshots?

Yes. Capture the broken screen, annotate what's wrong, and add a heading and description explaining expected versus actual behavior. Export it as a PDF bug report a developer can open and act on without a back-and-forth thread.

Can I create a QA report from screenshots?

Yes. Trace is built for exactly this — capture each step of a test pass, annotate the defects, and export a numbered PDF report with a cover page. It's used for regression testing, release notes and general QA documentation.

Can I generate software documentation or a user guide from screenshots?

Yes. Give each screenshot a heading and a short description of what's happening on that screen, put them in order, and export. The result reads like a proper user guide or piece of software documentation, not a folder of loose images.

Can I use Trace for SOPs and internal documentation?

Yes. Numbered steps, ordered pages and a consistent heading-and-description format make it a natural fit for standard operating procedures and other internal documentation that needs to be followed exactly.

Yes. There is no paid tier, no trial timer, no watermark on your exports and no feature held back. Install it and use it.

Do I need to create an account?

No. There is nothing to sign up for and no email to hand over. The extension works the moment it is installed.

Do my screenshots get uploaded anywhere?

No. Capture, annotation and PDF generation all happen inside your browser on your own machine. Your screenshots are never transmitted to us or to any third party, because there is no server involved in making the document.

Does Trace store my screenshots anywhere, or sync them to the cloud?

No. Screenshots stay in your browser's local storage until you export or delete them. There is no cloud account, no sync service, and no copy of your data anywhere outside your own device.

The full visible screen, a region you drag out yourself, or an existing JPG, PNG or other image saved on your device. All three land in the same queue, so you can mix a fresh screenshot with an older image in one report.

Can I create PDF reports from JPG or PNG images, not just live screenshots?

Yes. Use Upload from Device to bring in JPG, PNG or other image files you already have. They go into the same Report Editor as live captures, so a report can mix screenshots with images from any source.

Can I put my own branding on the PDF?

Yes. You can add a cover page with your title, subtitle, summary and logo, set custom footer text, and turn on a watermark. Page size, orientation, margins and image quality are all adjustable too.

Which browsers does it work in?

Chrome and any Chromium-based browser — Edge, Brave, Arc, Opera and Vivaldi included.

Does it work offline?

Yes. Once installed, capturing, annotating and exporting all work without an internet connection.

All posts

How to Write Effective Bug Reports with Annotated Screenshots

July 20265 min read

The most common complaint developers have about bug reports isn’t that there are too many — it’s that they don’t contain enough information. “The button doesn’t work” is a sentence, not a bug report. And even well-intentioned reports often leave out the one detail that would make the bug reproducible.

Annotated screenshots bridge this gap. They show the exact state of the UI, highlight the specific element that’s broken, and provide visual context that words alone can’t match.

Why most bug reports fail

A typical bug report contains a title, a description, and maybe some steps. But without visual evidence, several things go wrong:

Ambiguity.“The dropdown is broken” — which dropdown? On which page? In which state?
Missing environment details. The bug might only appear at a specific viewport width, with certain data, or in a particular browser. A screenshot captures all of this implicitly.
Back-and-forth. Without a screenshot, the developer has to ask clarifying questions, the reporter has to answer, and days pass before anyone looks at the actual code.

Anatomy of a good bug report

Every effective bug report answers five questions:

What happened? The observed behavior.
What should have happened? The expected behavior.
How do you reproduce it? Step-by-step instructions.
What’s the environment? Browser, OS, viewport, user role, data state.
What does it look like? Visual evidence.

The fifth question is where screenshots come in — and annotations are what make them useful rather than just decorative.

How annotations turn screenshots into evidence

An unannotated screenshot is a photo of a crime scene with no yellow tape. The viewer knows something happened but doesn’t know where to look. Annotations fix this by:

Directing attention. An arrow pointing at the broken element saves the developer from scanning the entire page.
Adding sequence.Numbered callouts (“1. Click here → 2. This field shows wrong value”) turn a static image into a walkthrough.
Highlighting absence. A circle around an empty space where a button should be is clearer than describing the missing element in text.
Capturing transient states. Tooltips, error messages, and loading states that disappear can be captured and annotated before they vanish.

Annotation tips

Use arrows and boxes, not freehand circles

Clean geometric annotations look intentional and are easier to follow. Freehand scribbles can look sloppy and make it unclear exactly what’s being highlighted.

Pick one highlight color and stick with it

Red is the convention for a reason — it stands out against most UI backgrounds. If you need a second color for a different type of callout (e.g., “expected” vs. “actual”), use green. More than two colors creates visual noise.

Add short text labels

An arrow is good. An arrow with the label “wrong total” is better. Keep labels short — three to five words — so they don’t clutter the image.

Show before and after when possible

If the bug involves a state change, capture both states: the correct behavior and the broken behavior. Place them side by side or in sequence so the contrast is obvious.

Crop thoughtfully

Too tight and you lose context. Too wide and the bug gets lost. Include enough surrounding UI to orient the viewer (the page header, the form section) but not the entire browser window.

From screenshots to report

For simple bugs, a single annotated screenshot pasted into a Jira ticket is enough. But for complex issues — multi-step reproduction, cross-browser comparisons, or regression testing — combining multiple screenshots into a single PDF report makes the bug report self-contained and easy to reference.

Tools like Trace are built for exactly this workflow: capture screenshots in the browser, annotate them in place, arrange them in order, and export the whole sequence as a numbered PDF. The report becomes a single attachment that tells the complete story of the bug.

Whatever your tooling, the principle holds: a bug report with annotated screenshots gets resolved faster because it removes ambiguity. The developer sees exactly what you see — and that’s half the battle.

Creating Standard Operating Procedures (SOPs) with Screenshots Screenshots vs. Screen Recordings: When to Use Each