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 Create a QA Test Report (Step-by-Step Guide)

July 20266 min read

A QA test report is the bridge between testing and fixing. When it’s done well, developers can reproduce the issue, product managers can prioritize it, and nobody needs to schedule a call to ask “what exactly is broken?” When it’s done poorly, the report sits in a queue until someone has time to decipher it.

The difference between the two isn’t effort — it’s structure. A clear template and the right visual evidence turn a 20-minute writing task into a 5-minute one that actually gets results.

What a QA test report should include

Every test report needs to answer the same set of questions, regardless of whether it’s a single bug or a full regression cycle:

Summary. One or two sentences: what was tested, what was found. A reader should be able to decide whether to keep reading based on this alone.
Environment. Browser, OS, device, app version, test account used. Bugs that only appear in specific environments are common — this section prevents wasted debugging time.
Test cases and results. What you tested, what the expected outcome was, and what actually happened. For passed tests, a simple checkmark is enough. For failures, detail is critical.
Steps to reproduce.Numbered steps that anyone can follow to see the same issue. Be specific: “click the Submit button on the checkout page” is actionable; “submit the form” is not.
Visual evidence. Annotated screenshots showing exactly what went wrong. This is the most underused and most valuable part of a QA report.
Severity and priority. How bad is it, and how urgently does it need to be fixed? A broken payment flow is critical; a misaligned icon is low.

Step-by-step: creating the report

Step 1: Define the scope before you test

Start by listing exactly what you’re testing. A focused scope like “checkout flow on mobile Chrome” produces a more useful report than “tested the app.” The scope also sets expectations for stakeholders about what wasn’t covered.

Step 2: Capture screenshots as you test

Don’t wait until after testing to go back and take screenshots. Capture as you go — especially for failures, where the exact state of the UI is evidence. Include both the expected state and the actual state when possible.

For web applications, a browser-based capture tool is most efficient. You’re already in the browser testing; staying there to capture and annotate avoids the context switch of saving files, opening an image editor, and copying results back.

Step 3: Annotate with intention

A raw screenshot shows a page. An annotated screenshot shows a problem. Use arrows to point at the broken element, boxes to highlight the relevant area, and short text labels to explain what’s wrong. Numbered steps on the screenshot can map directly to your reproduction steps.

Step 4: Organize by test case, not by order taken

Group your findings by feature or test case, not by the order you happened to find them. A report organized around “Login flow — 2 failures” and “Search — passed” is immediately actionable. A chronological dump of 15 screenshots is not.

Step 5: Export as a single document

The final report should be one file — a PDF with numbered pages, a cover page with the test scope and date, and each finding on its own page with the annotated screenshot and written details. One attachment is always easier to share, reference, and archive than a folder of images.

Common mistakes in QA reporting

No screenshots.Text-only bug descriptions are ambiguous. “The button is in the wrong place” means nothing without a visual.
Screenshots without annotations. A full-page screenshot without any indication of where the issue is forces the reader to play detective. Always add at least an arrow or highlight.
Missing reproduction steps.“It just broke” is not a reproduction step. If the developer can’t reproduce it, it won’t get fixed.
Burying severity. Lead with the critical issues. If a developer has to read through 10 minor UI issues before reaching the broken payment flow, the critical bug may not get the attention it needs.
Reports that are too long.Include everything relevant, nothing that isn’t. Passed tests that had no issues can be summarized in a line. Failed tests get the detail.

Choosing a format and tool

Spreadsheets work for tracking large test suites but are poor for visual evidence. Documents handle screenshots well but become unwieldy at scale. PDFs combine the best of both: structured, visual, easy to share, and they preserve layout across any device.

For browser-based QA testing, tools like Trace handle the entire cycle — capture, annotate, organize, and export — without leaving Chrome. The screenshot-to-PDF workflow means the report is structured by default: numbered pages, cover page, and consistent formatting. No manual layout work required.

Whatever tool you use, the goal is the same: a report that a developer can pick up, understand the issue, reproduce it, and fix it — without needing to message you for clarification.

How to Document a Process Step by Step Visual QA Testing: A Complete Guide for Web Applications