Turn a Recording Into a Report Someone Can Act On
Load the screen recording of the bug. Play it, and each time something happens that matters, mark it. The timestamp is captured, a frame is grabbed from the video at that moment, and the step goes into a numbered list.
Write the summary, what you expected and what happened instead, then copy the whole thing out as Markdown for GitHub, Jira markup, or plain text. The browser and screen details are filled in already.
The recording never leaves your machine. It is played from a local file and frames are drawn on your device, which matters when the bug is in an unreleased build or a customer’s account.
A Timestamp Per Step
Mark a moment and its playback time goes into the numbered list.
A Frame Per Step
A still from the video at each marked moment, ready to attach.
Environment Filled In
Browser, operating system, screen and viewport, read from your browser.
Markdown, Jira or Plain Text
Copy the finished report into GitHub, Jira or anywhere else.
Why This Does Not Use AI to Write the Report
A model watching a screen recording can describe what it sees. It cannot know what you expected to see, and that is the half of a bug report that decides whether anyone can act on it.
“Clicked Confirm, the invoice panel was empty” is an observation. Whether that is a bug depends entirely on what should have appeared there, and the only person who knows that is you. A tool that generates expected behavior from a video is guessing and presenting the guess as a finding, which is worse than leaving the field blank, because a plausible wrong expectation sends a developer down the wrong path.
So the split here is deliberate. The tool does the mechanical work it can do exactly: timestamps, frames, environment, formatting, numbering. You supply the judgment. That takes about a minute and the result is a report nobody has to come back to you about.
The Three Things Reports Usually Miss
Having read a lot of thin bug reports, the same gaps recur, and all three are mechanical rather than hard.
Timestamps. A report that says “see the attached video” makes the reader watch four minutes to find the moment. A step that says it happened at 1:12 does not.
Environment. Browser, operating system, screen size. Everybody knows to include it and almost nobody does, because it means opening a settings panel while you are mid-thought. It is read from your browser here and sits in the report already filled in, and you can correct it.
Stills. A frame at the moment of failure is what gets scanned in a list of twenty issues. Pulling frames out of a video by hand is tedious enough that people skip it, so it happens automatically at each step you mark.
What Gets Captured, Precisely
Each marked step records the exact playback time and a JPEG frame from the video at that time, scaled down to keep the report light. You can download the frames to attach to the issue.
Environment comes from the browser: its name and version, the operating system, the screen size with its pixel ratio, and the viewport size. Browsers now report less about themselves than they used to, so some of those can come back unknown, and every field is editable rather than locked.
Nothing is inferred from the pixels. The tool does not try to read error text off the screen or guess which element you clicked, because doing that unreliably is worse than not doing it.
The Structure It Fills In
The output follows the shape a bug report has settled on, because trackers and the people reading them expect it. If you have been looking for a bug report template, this is one that arrives already filled in rather than one you paste and stare at.
Summary first, in a single line, because that line is what someone scans in a list of thirty issues and it decides whether yours gets opened today.
Then numbered steps with the timecode on each, expected behavior, actual behavior, and the environment. That order is not decoration. A reader checks the steps to see if it is reproducible, the expected and actual pair to see if it is really a bug, and the environment to see if it is theirs. Burying any of those costs a round trip.
What a blank template cannot do is fill itself in, which is the part that makes people skip it. Here the steps, timecodes, frames and environment arrive populated, and you write the three fields a tool genuinely cannot know.
Before You Record
The report is only as good as the recording, and two habits make the difference.
Start from a known state. A recording that begins mid-session leaves the reader guessing what came before, so the steps stop being reproducible. Begin at a login screen, a fresh page, or a described starting point.
Clear the screen of anything that should not travel. Tokens in a URL bar, a customer’s name, an unrelated email in another tab, an API key in a devtools panel. A bug report gets forwarded, pasted into chat and read by people outside the team, and a screen recording carries whatever was on screen at the time. This tool never uploads the video, but the report and the frames go wherever you send them.
Record a Bug Someone Can Reproduce
Start From a Known State
A login screen or a fresh page.
Clear the Screen
No tokens, names or keys in view.
Mark Each Step
The timestamp and frame are captured.
What It Does Not Do
It does not file the issue. There is no connection to GitHub, Jira or anything else; you copy the report and paste it where it belongs, which also means you get to read it before anyone else does.
It does not capture logs, network requests or console output. Those live in your developer tools and matter enormously for some bugs. Attach them through whatever secure route your team already uses rather than filming a console.
And it does not diagnose anything. It will not tell you the cause, which component is at fault, or whether this duplicates an existing issue. It gets the evidence into a shape somebody can work from, and that is the whole job.
Good at
- Timestamps, frames, environment and formatting, done exactly
- Recordings of unreleased builds, since nothing is uploaded
- A report that follows the shape trackers expect
Not built for
- Filing the issue in GitHub or Jira for you
- Logs, network requests or console output
- Diagnosing the cause or spotting duplicates
Recording the Bug in the First Place
If you still need to capture the problem, the screen recorder records a tab, a window or the whole display in the browser. For a bug you need to narrate while you reproduce, record with audio and the explanation stays attached to the evidence.
Two neighbors worth knowing. If you want single images rather than a report, the video frame extractor pulls frames at intervals. And if the recording is long and you want the spoken walkthrough as text, the transcript generator turns the narration into something searchable.
Ask the Recording About the Bug
The check on this page runs on your device and needs no account. For answers about what was said or shown in the recording, upload it to ScreenApp. Click a question to open ScreenApp with it ready to ask.
In ScreenApp, clicking a moment in the transcript jumps the player to that point in the recording, so you can check any answer against the recording.
What Each Plan Does Here
The tool on this page is free and stays free. An account is for the step before it or the step after it.
Build the Report
Mark steps on a recording you already have and copy the report out as Markdown or Jira, with nothing uploaded.
Record the Bug
No card needed. Record your screen in ScreenApp and share a link with the transcript, so the developer hears what you said at each step. The free plan covers 2 transcriptions of recordings up to 45 minutes each and 10 AI chats a month.
7 Days to Try Pro
Pro is $19 a month billed annually, with 50 transcriptions and 50 AI chats a month. Use every Pro feature for 7 days and confirm it does what you need before the first payment. The trial is for annual plans only. Trial terms: Card required. See the plans and terms.
