You changed it. Nothing moved. The browser had the answer the whole time.
DevTools shows you the CSS rules. It doesn’t tell you which one is winning, where it came from, or why every other rule lost.
.entry-content a · theme · style.css · !important
→Your rule lost because it uses !important with a more specific selector
→inline style lost because the winning rule loads later on the page
You changed it. Nothing moved.
The browser had the answer.
7-day free trial No card required Any website in Chrome
Three things a skeptic should know first.
Lens is a pre-launch product. It does something no other tool does. So it’s worth being specific about exactly what it does, what it doesn’t, and what happens if it isn’t conclusive.
After you click, a colored outline appears on the element you selected, visible on the page behind the Lens popup. The inspect panel shows you the computed styles on what was captured. If the wrong element was captured, you see it immediately and can cancel before the diagnosis runs.
CSS is infinitely varied and Lens won’t get every case right. When the data isn’t there to make a confident finding, the diagnosis says that. No false confidence. The capture file is still yours to download and pass to a developer. Everything a developer needs to diagnose without follow-up questions is already in it.
If the data isn’t there, Lens says nothing about that property. No guessing. No false confidence. What it can trace, it reports correctly. What it can’t, it leaves blank. That silence is intentional.
The answer is in DevTools. It just never tells you what it is.
DevTools is an inspector for people who already understand CSS. It shows you data. It doesn’t read it for you, name the source of each rule, or tell you why one rule beat another. Lens does the reading.
DevTools
Shows a list of CSS rules applying to the element
Crosses out overridden rules. Doesn’t say why they lost
Shows one element at a time. No parent context
Doesn’t name the source. A rule is a rule, no origin label
No verdict. No next step. No override CSS
Loupely Lens
Every rule that applied, and every rule that lost, with the specific reason it lost
The full parent chain: every ancestor with its layout constraints flagged
Origin labels on every rule across 14 categories: theme, page builder, plugin, inline, JavaScript, browser default, and more
A rule engine reads the capture data and produces a verdict: what’s winning, what lost, and why
A ready-to-paste CSS override when one is possible, and a developer handoff package when it isn’t
Not just the winning rules. Every rule that had an opinion.
The reason your page builder setting is being ignored is almost never visible in the winning rules. It’s in the rules that lost. Lens captures both.
Every CSS property rendered on this element: which rule set each value, the selector that matched it, the specificity score, and the source file. Not just the value: the full story behind it.
Why this matters
DevTools shows you the Computed panel. Lens goes further: it tells you exactly where each winning value came from and why it won. That’s why the verdict can name the source (“your page builder wrote this directly onto the element”) instead of just reporting the value.
Every CSS rule that tried to set a property on this element and was overridden. The selector, the source, the specificity score, and what beat it. The loss reason for each: lower specificity, source order, !important, @media mismatch, or @layer order. This is what DevTools shows as crossed-out lines with no explanation.
Why this matters
Your CSS rule is in here. The thing beating it is also in here. Lens finds both, names them, and explains why one won. That’s why the verdict can say “your theme is overriding your page builder” instead of “something is conflicting.”
Every rule is classified by source: theme stylesheet, page builder cache, plugin (external or internal), WPCode snippet, inline style attribute, JavaScript injection, CSS-in-JS, browser default, and more. File path and line number included where available. This classification runs on the capture, before the diagnosis runs.
Why this matters
Without origin labels, all you see is a list of rules with no context for which ones you control. A plugin-injected style requires a different fix than a theme stylesheet. Lens tells you both so the next step is actually actionable.
The specificity score for every competing rule. Load order. Whether a rule uses !important. All competitors ranked. And an override prescription: the suggested selector, whether !important is required to win, and confidence level.
Why this matters
When you write a CSS rule and nothing happens, something with a higher score is beating it silently. Lens shows you the score of the rule you need to beat, so any CSS override it generates actually wins, not just adds another losing rule to the stack.
When a property value uses var(–), Lens traces the chain from the element where the variable is called all the way to where it’s defined, recording the value at each depth level. The resolved value and the definition point are both captured.
Why this matters
CSS variables cascade invisibly. A color set via var(–brand-color) might be redefined at a dozen different scopes. Without tracing the chain, you can’t know which definition is actually controlling the value. Lens traces it so the override prescription can tell you exactly where to change it.
When a ::before or ::after pseudo-element has non-null content, non-zero dimensions, or a non-default background-color, its full computed styles are captured alongside the element itself.
Why this matters
Pseudo-elements are one of the most common causes of “something is overlapping but I can’t click on it.” DevTools shows them, but Lens captures their styles in the same structured format as everything else, so they show up in the diagnosis if they’re the cause.
The problem is usually not on the element you can see.
A section that won’t center is almost never blocked by a rule on the section itself. It’s a fixed width, a flex property, or an overflow setting on a parent element two or three levels above it. Lens reads the whole chain without you having to know where to look.
Every element in the DOM hierarchy above the one you clicked, captured to the document root. Width, max-width, overflow, display, flex and grid properties, position, z-index: every property that could constrain a child. 68 CSS properties per ancestor, same as the target element.
Why this matters
When a section won’t center, the constraint could be on any element from the section all the way up to the body. Most centering problems are caused by a parent, not the element you’re staring at. Lens shows the entire chain so the problem is findable wherever it is.
Ancestor properties likely to be causing the problem are flagged: display:none or visibility:hidden on a parent, overflow:hidden clipping content, width or flex constraints blocking centering, z-index conflicts, blend mode interactions, and spacing causes. Flagged ancestors surface first in the rule engine output.
Why this matters
You don’t have to inspect each parent element one at a time. Lens surfaces the flagged ancestor first. Most centering, overflow, and layout problems come down to one constraint on one parent. That’s where the verdict starts.
Every stacking context created by ancestors, including those created by transform, opacity, filter, or will-change. The z-index of the clicked element within its context, and whether a competing element is rendering above it.
Why this matters
Overlapping elements are almost always a stacking context problem. Setting a higher z-index doesn’t fix it if a parent with transform or opacity has already confined the element to its own context. Lens reads the full tree so the overlap verdict names which ancestor created the problem.
Lens reads the evidence and names the problem. You don’t have to describe it.
Before the rule engine produces a verdict, it has already read the structured capture fields: what’s competing, what’s dangerous, what the cascade resolved to. That’s why the verdict opens with a specific finding instead of a question.
Siblings in the same flex or grid container, elements with overlapping absolute or fixed positioning, elements sharing a stacking context. Their CSS properties captured alongside the target so the relationship is visible.
Why this matters
When something is being pushed out of position, the cause is usually on a different element than the one you clicked. Lens detects which other element is involved without you having to find it and click it separately.
A specific set of CSS conditions are flagged on the target and all ancestors: very low opacity, a color that vanishes against the background, a transform pushing the element offscreen, a buried z-index, a clip-path set to zero, or text that’s invisible on a dark background. Each is flagged with the specific property and value causing it.
Why this matters
“The element is there but I can’t see it” is one of the hardest problems to diagnose visually. opacity:0.01 on a parent. A transform: translateX(-9999px) that looks fine in the DOM. A color that matches the background at exactly the wrong contrast. Lens flags these before the rule engine runs, so they surface in the verdict if they’re the cause.
content.js classifies the most likely problem type from the capture data before the diagnosis runs. The rule engine reads this classification and selects the right verdict template from a priority-ordered set. The user sees the verdict, not the classification code. Each classification has a confidence level, so if the data is ambiguous, the engine knows before it commits to a finding.
Why this matters
The verdict doesn’t start with a question. It starts with a finding derived from the data. The classification is what makes that possible: the rule engine already knows whether it’s looking at a color conflict, a layout constraint, an overlap, or something else before it writes the first word of the output.
Viewport width and height at the moment you clicked. Every @media query active at that viewport. Every @media query that would activate at common breakpoints. Applied class list on every element in the ancestor chain.
Why this matters
When something breaks only on mobile, the capture reflects what was actually on screen when you saw the problem. Not a desktop reconstruction. The verdict runs on the real state, not a guess about which breakpoint might be involved.
Did what you just changed actually do anything?
When you capture the same element twice in the same session, Lens compares the two captures. Every property that changed between them is recorded and assessed. Every property that didn’t change is also recorded. You can see whether your edit had any effect at all before the diagnosis runs.
Every property in the 68 TOUCH_LIKELY_PROPERTIES set is compared between the two captures. Changed properties are assessed as FIXED (value changed, not browser-default), REGRESSED (moved further from browser-default), or CHANGED (ambiguous; review whether this is correct). Unchanged properties are also listed. The comparison is conservative: when in doubt, it uses CHANGED rather than claiming a fix.
Why this matters
“Did my change do anything?” is the question you ask after every CSS edit. The session diff answers it before the diagnosis runs. If your change registered on the element but didn’t fix the visual problem, the diff shows both facts: the property changed, and here’s what’s still beating it. If your change didn’t register at all, the diff shows that too.
A complete CSS dossier. Available on the triage page after a diagnosis.
Every diagnosis includes a downloadable capture file on the triage page. A developer who receives it has everything they need to understand the problem without follow-up questions: every question they would ask is already answered in the file before the conversation starts.
Click on what looks wrong.
Finally know what is causing it.
7-day free trial, no card required. Unlimited diagnoses with the annual plan.