Point at the line that actually matters.
A capture can hold two thousand events. Exactly three of them explain the bug. Highlights let you mark those three and write down why, so the next person opens the capture already looking at the right row instead of scrolling for ten minutes.
All features/assets/img/highlights.pngA note pinned to a single event.
Select any row in the analyzer, whether it is an HTTP request, a console line, a WebSocket frame or a server-sent event, and attach a highlight to it. A highlight is a marker plus free-text notes, and it is stored as part of the capture rather than alongside it.
That means highlights survive everything the capture survives: export to a file, upload to the Cloud Gallery, a shared link opened by somebody who has never installed webQsee. The person on the other end sees your reasoning next to the evidence it refers to.
- Any number of highlights per capture
- Several highlights can sit on the same event
- Each one records who wrote it and when it last changed
- Teammates can add their own without overwriting yours
What people write in them
- "This 500 is the one, the two before it are retries."
- "Token is already expired here, look at the exp claim."
- "Everything after this frame is the reconnect loop."
- "@backend, this is your call, not ours."
Short, specific, attached to the exact row. The kind of thing that would otherwise get lost in a chat thread three days later.
Enough tracker to stop things falling through.
webQsee is not trying to replace Jira. It is trying to stop the twelve captures in your gallery from becoming twelve unlabelled files whose meaning you have already forgotten.
| Field | Values | What it is for |
|---|---|---|
| Status | open · in progress · done · invalid · rejected | Where this capture stands. Rendered as a pill on the gallery card, so a glance across the grid tells you what is still live. |
| Priority | marginal · low · normal · high · critical | How much it matters. Normal is the default and is not shown, so only the exceptions catch your eye. |
| Title | free text | What you would have called the ticket. Travels with every share link. |
| Description | free text | The reproduction steps, the expectation, the actual result. |
| Notes | free text | Your working notes. Separate from the description so the shared story stays clean. |
| Type | capture kind | Behavior report, event snapshot, screenshot, video or imported file. |
Who may change what
In the Local Gallery, everything is yours to edit. In the Cloud Gallery, the owner can always edit; letting other team members edit shared items is a Small Team and Team feature. Highlights are additive either way, so a reviewer can annotate without touching your metadata.
From "here's a capture" to "here's the finding".
An unannotated capture is a pile of evidence that transfers the work rather than the conclusion. The receiver has to redo the analysis you already did, which is most of the reason bug reports bounce back and forth.
A capture with a title, a priority, and three highlighted rows carrying one sentence each is a finished piece of work. It survives being read next Tuesday by somebody who was not in the room.
Typical pass
- Reproduce the bug with webQsee capturing.
- Highlight the two or three events that prove it.
- Title it, set the priority, leave it open.
- Share the link into whichever channel your team lives in.
- Whoever picks it up flips it to in progress, then done.
Stop guessing. Start webQseeing.
Add webQsee to Chrome or Edge in one click. Most features are free, forever, no signup needed. Upgrade only if your team needs cloud sharing, S3 storage and Pro-grade tooling.
Works in Chrome 103+, Edge 103+ and most Chromium-based browsers. Install instructions.