Screenshot or console log: which one do you actually need?
What each artifact proves, where each one misleads, and why the argument between them is the wrong argument.
Bug reporting tools tend to lead with one or the other. The visual-feedback tools sell the screenshot with arrows on it; the developer tools sell the stack trace. Teams then argue about which they need, which is the wrong question — they answer different halves.
What a screenshot proves
A screenshot is evidence about rendering. It shows what the interface looked like, which is the only reliable record of a class of bugs that leave no trace anywhere else:
- Layout broken at a particular width
- An element overlapping another
- The wrong copy, the wrong currency, the wrong language
- A loading state that never resolved
- Something that looks wrong but throws nothing
That last one matters more than it sounds. A large share of real user complaints are about pages that are working perfectly according to every technical signal you have.
Where a screenshot misleads
It is one frame, and the frame is chosen by someone who does not know what you need. It is usually taken after the person has already reloaded, navigated away, or dismissed the thing they were complaining about.
It also carries no state. A screenshot of a blank dashboard is indistinguishable from a screenshot of a dashboard belonging to an account with no data.
What a console error proves
A stack trace is evidence about execution. It gives you a file, a line and a column, and a chain of calls that got there. For a bug that throws, it is close to a direct pointer at the defect.
It is also the artifact that survives compression best. One TypeError with three frames is worth more than four paragraphs of description, and it needs no interpretation.
Where a console error misleads
Two failure modes, both common.
The first: many real bugs throw nothing at all. A form that silently discards input, a filter that returns the wrong rows, a total calculated incorrectly. Your console is clean and your user is right.
The second: the loudest error is often not the relevant one. Pages throw noise — a failed analytics beacon, a blocked third-party script, a warning from an extension. An error captured at the moment of a report is only useful if you can see whether it relates to what the person was doing.
Which is why the answer is both, plus a third thing
Screenshot tells you what it looked like. Stack trace tells you what executed. Neither tells you what the person was trying to do, and that is the piece that decides whether the other two mean anything.
A report with all three — the picture, the exception, and the sentence "I was trying to apply my discount code" — is a bug you can act on immediately. Any two of the three still leave you guessing.
A practical rule
If you are picking a tool and can only optimise for one, pick by what your bugs look like.
Mostly visual and layout problems, reported by non-technical reviewers on a site you are building for someone else? The screenshot and annotation tools earn their keep. Mostly application errors reported by users of a product with real state? The technical context matters more, and a screenshot alone will send you in circles.
Most teams have both kinds, which is why the argument keeps happening.