What Lens is designed for #
Lens is a CSS diagnostic tool. It reads the visual CSS state of elements in the browser and explains why they look the way they do. Any visual problem caused by CSS rules, specificity conflicts, cascade order, inheritance, ancestor constraints, or competing elements is in Lens’s diagnostic range.
That covers a large proportion of visual problems on real websites: most layout issues, most color and typography problems, most spacing problems, most “why won’t this center” and “why is this the wrong size” problems, and most “I changed the setting and nothing happened” problems.
What Lens diagnoses well #
- Colors, fonts, and typography that don’t match what you set in your Page Builder or theme
- Elements that won’t center, align, or position correctly
- Sections or containers that are the wrong width or height
- Elements being cut off or hidden by overflow constraints on parent containers
- Layouts that break at specific screen sizes
- Elements that appear behind other elements when they should be in front (z-index conflicts)
- Styles set in a Page Builder that aren’t taking effect because something else is overriding them
- Styles injected by a plugin that are overriding your theme or Page Builder settings
What Lens can’t diagnose #
Elements inside web components (Shadow DOM) #
When you click an element that lives inside a Web Component, Lens shows this message: “This element is inside a Web Component. Internal styles aren’t accessible through standard CSS. Try picking the outer element.” No diagnosis is counted. The capture is cancelled before it starts. Try clicking the outer wrapper element instead, which Lens can read normally.
CSS-in-JS with runtime class names #
Some JavaScript frameworks generate CSS at runtime with randomly generated class names that change on every build. Because the class names are unpredictable, Lens can’t trace a rule back to a stable source, and any override prescription would break on the next deploy. Lens routes these to developer handoff rather than generating a fix it can’t guarantee.
Styles set by JavaScript directly on the element #
When JavaScript sets a style directly on an element’s style attribute at runtime (not through a stylesheet, not through a class), the result is an Inline Style with no stable origin to override. Lens identifies it and routes to developer handoff. The fix requires changing the JavaScript, not adding a CSS rule.
Active, hover, and focus state styling #
Lens captures the default CSS state at the moment you click. It doesn’t capture what an element looks like on hover, when it’s active, or when it’s focused. If the problem only appears when you interact with the element, the CSS evidence won’t be present in a default-state capture.
Elements inside cross-origin iframes #
Browser security restrictions prevent any extension from reading the contents of an iframe that loads from a different domain than the main page. If the element you’re trying to diagnose is inside an embedded third-party widget (a payment form hosted by your payment provider, an embedded social media feed, a third-party chat widget), Lens can’t access its CSS state.
Functional failures #
If something isn’t working (a form that won’t submit, a checkout that fails, a login that errors), that’s a functional problem with JavaScript or server-side code, not a CSS problem. Lens reads CSS state, not JavaScript logic or server responses.
Performance problems #
Slow loading, layout shift during page load, and animation jank are performance issues. Lens doesn’t measure load times or frame rates.
When the capture completes but classification doesn’t #
If Lens captures the element but can’t match the CSS data to a known problem pattern, it routes to capture-insufficient rather than producing a guess. The capture file still contains the full CSS picture. Download it from the Triage Page and share it with a developer. See Triage Routes for Lens for what to do from there.