When the diagnosis feels off #
If Lens produces a diagnosis but it doesn’t seem to describe the visual problem you can see, or the triage step it suggests doesn’t resolve the problem, something in the capture chain went wrong. This doesn’t mean Lens is broken. It means 1 of a few specific things happened that are usually easy to identify and correct.
You captured the wrong element #
This is the most common cause. On densely built pages, a click can land on a parent wrapper, a sibling element, or an invisible overlay rather than the specific element you intended. The diagnosis accurately describes the CSS state of the element that was captured. It just wasn’t the right element.
How to check: the Lens popup should show the CSS class name or element type that was captured. If that doesn’t match the element you were trying to diagnose, try again. Deactivate Lens, reactivate it, and click more precisely. For very small elements, zoom in on the page (Ctrl+plus or Cmd+plus) before clicking.
If the problem is a section that won’t center, click directly on the section’s outer container rather than the content inside it. If the problem is a button that’s the wrong color, click the button’s visible face, not any text or icon inside it.
The cause is in the ancestor chain, not on the element #
Lens traverses the ancestor chain automatically, but the diagnosis names the most likely cause of the problem. If the ancestor constraint is subtle or involves a distant grandparent, the diagnosis may focus on the element’s own CSS rather than the ancestor constraint.
If the triage step doesn’t resolve the problem after you follow it, download the capture file and share it with your developer. The capture file includes the full ancestor chain. A developer reading it will often spot the constraint immediately even when the automated classification focused elsewhere. See The Lens Capture File for how to use the file for developer handoff.
The problem was caused by JavaScript after the capture #
Some CSS problems only appear when JavaScript has run and modified the page after load: a slider that loads in the wrong position, a modal that appears with incorrect styles, a menu that opens with a layout problem. If Lens captured the element in its pre-JavaScript state (before the interaction that triggers the problem), the CSS state it read may look correct because the problem hadn’t occurred yet.
Fix: trigger the visual problem first (open the menu, open the modal, run the slider), then activate Lens and click the broken element while it’s in its broken state. Capturing in the broken state gives Lens the actual CSS that’s causing the problem.
The problem is not a CSS problem #
If an element looks correct but doesn’t work (a button that clicks but nothing happens, a form that appears to submit but nothing gets sent), the problem is functional rather than visual. Lens is a CSS diagnostic tool. It reads visual styling. It can’t diagnose broken JavaScript or server-side failures.
The diagnosis identified a contributing factor but not the root cause #
In some cases, Lens correctly identifies a CSS issue but the issue it found is a symptom of a deeper structural problem. For example, Lens might identify that a parent container has a fixed width causing a centering failure, and that’s accurate, but the reason the parent has that fixed width is that a plugin is injecting it via JavaScript at runtime. The diagnosis points you to the parent container. The deeper cause is the plugin.
When acting on a triage step doesn’t fully resolve the problem, the capture file is the next step. Download it and ask your developer to look at the full ancestor chain and origin classification data for any JavaScript-injected styles. Those often don’t surface in the primary diagnosis but are visible in the raw capture data.