When QA teams evaluate bug reporting tools, one of the first questions is: "What does it capture?" Session replay and page snapshots are the two most powerful artifacts in modern bug reports. They sound similar but answer completely different questions — and you need both.
Here's what each captures, what question it answers, and when each one is the deciding factor in a fast fix.
Session Replay: What the User Did
Session replay is a recording of everything the user did during their session: every click, every scroll, every navigation, every input. It's a video (reconstructed from DOM events, not a screen recording) that shows the exact sequence of actions that led to the bug.
What Session Replay Answers
- What did the user do before the bug appeared?
- Which path did they take through the application?
- Did they do something unexpected that might have triggered the bug?
- Is this bug reproducible by following their exact path?
When Session Replay Is the Decisive Evidence
Session replay matters most for path-dependent bugs — bugs that only appear after a specific sequence of actions.
Example: "The checkout summary shows the wrong total." The bug only appears when the user navigates from a specific product page, adds to cart from a modal (not the product page), and then applies a promo code before checkout. This sequence is nearly impossible to document in written reproduction steps. Session replay shows it in 30 seconds.
Page Snapshots: What the Page Contained
A page snapshot captures the complete DOM state at the moment of the bug — the actual HTML structure, the actual data values, the computed styles, the component state. Unlike a screenshot, a page snapshot is openable in a browser's DevTools, where you can inspect every element, check every value, and query the DOM.
What Page Snapshots Answer
- What data was on the page at the moment of failure?
- What values did the components contain?
- What did the DOM tree look like — not just what it rendered?
- Was the wrong data on the page, or was correct data displayed incorrectly?
When Page Snapshots Are the Decisive Evidence
Page snapshots matter most for data-driven bugs — bugs where the display is wrong because the underlying data is wrong.
Example: "The invoice shows $0.00 instead of $247.50." Session replay shows the user navigated to the invoice. But the page snapshot shows that the total component received a prop of null instead of a number — immediately telling the developer the bug is upstream (the API returned null instead of the total). Without the page snapshot, the developer would need to recreate the exact invoice and reproduce the API response to find this.
The Two Questions They Answer
| Question | Session Replay | Page Snapshot |
|---|---|---|
| What did the user do? | ✓ Yes | ✗ No |
| What data was on the page? | ✗ No | ✓ Yes |
| What was the sequence of events? | ✓ Yes | ✗ No |
| What were the component values? | ✗ No | ✓ Yes |
| Can it be inspected in DevTools? | ✗ No | ✓ Yes |
| Does it show the path to the bug? | ✓ Yes | ✗ No |
Why You Need Both
Most real bugs need both artifacts. Session replay tells the developer how to get to the bug. Page snapshot tells them what to look for once they're there.
A report with session replay but no page snapshot shows the developer the path but not the cause. They can reproduce the sequence, but now they have to inspect the DOM themselves.
A report with page snapshot but no session replay shows the developer the cause but not the path. They can see what was wrong, but they don't know how to get back to that state.
Together, the two artifacts make a report self-contained: the developer watches the session replay to understand the path, opens the page snapshot to inspect the cause, and starts fixing without needing to reproduce anything.
