You added a border. You saved, refreshed, cleared the cache. The border isn’t there. Or it was there last week, and now it isn’t, and you haven’t touched that element since.
That’s not a mistake on your end. That’s a visibility problem. Something in the CSS is overriding the border you set, and without a way to see which rule is winning, you’re left refreshing the page hoping the answer reveals itself.
It won’t. But there’s a way to find it.
Why CSS borders disappear
A missing border almost always comes down to one of three things: the border was set but something else overrode it, the border color blends into the background so it looks absent when it isn’t, or the border-box model is collapsing it in a way that makes it invisible. These aren’t rare edge cases. They’re the standard causes, and they’re invisible without reading the full CSS picture.
A rule with higher priority is setting border: none
This is the most common cause. Your theme, your page builder, or a plugin has a CSS rule that explicitly sets border: none or border-width: 0 on that element — and that rule is winning. Your border isn’t missing. It’s losing a competition you didn’t know was happening.
I know this pattern from every direction. When I was customizing the category menu sidebar on BetterDocs — the plugin I use for the knowledge base — I’d set new CSS styles, refresh the cache, and the page would look exactly the same. Every time. It was like I was adding my code to a completely different website, because the one I was refreshing wasn’t responding to anything I wrote. The BetterDocs styles had higher priority than everything I was adding, and I had no way to see that without being able to read the full stack of rules applying to that element.
That’s what a specificity conflict looks like from the outside. Not an error. Not a warning. Just nothing happening, over and over, while you try different things.
The border color matches the background
The border is technically there. It’s just invisible because the color is set to something that blends with whatever is behind the element. White border on a white background. Transparent border where the default was supposed to inherit something. This one’s rarer, but it produces the same experience: you set a border, you look for it, it isn’t there.
The box model is collapsing it
If the element has box-sizing: border-box and a fixed height that’s too small to accommodate the border alongside the padding and content, the border can effectively disappear. This happens most often on elements that were sized at some earlier point and haven’t been revisited since.
The hardest version: the border disappeared after an update
There’s a specific version of this that’s worse than the rest, because it adds a layer of loss on top of the confusion. You had the border. It was right. Then something updated — a theme, a plugin, a page builder — and it’s gone.
I’ve been through this with plugin customizations, and the particular cruelty of it is that you spent real time getting it right, and then something outside your control quietly undid it. I had fully customized the Dokan plugin’s product editor — down to the pixel of every element, days of work — and then they updated the editor to a React framework. They kept the legacy version available, but I knew any future update would pull it. The customization I’d spent days on was already living on borrowed time, and the update came just days after I’d finished. I was frustrated beyond belief. Not because I’d done anything wrong, but because something I couldn’t see had changed underneath me.
A border disappearing after a theme update is the same shape of problem. The rule that was letting your border show — maybe because nothing was overriding it — is now competing with new stylesheet rules that arrived with the update, and one of them is winning with border: none. Your border didn’t break. It lost.
Why articles about this miss the point
Most explanations of missing CSS borders walk you through the possible causes in the abstract — border: none, color mismatch, box model — without accounting for the specific stack you’re working with. They don’t know you have a page builder generating its own styles, a plugin adding its own stylesheet, a theme with high-specificity rules, and your custom CSS on top of all of that. Their answer is for a theoretical site with one stylesheet. Yours isn’t that.
The fix for a border that’s being overridden by BetterDocs is different from the fix for one being overridden by Elementor, which is different from the fix for a Shopify theme. The mechanism is the same — something has higher priority than your rule — but where that something lives, and how to target it, depends entirely on your setup. Generic answers don’t give you that.
What “finding the override” actually means
When your border isn’t showing, the information you need is specific: which rule is winning, and where did it come from. Not a list of things it might be. The exact rule, in the exact stylesheet, that is overriding what you set.
When I’m in that state — head scrambled, holding all the things I’ve already tried alongside all the things I still have left to try, tracking previous fixes that worked in similar situations while also trying to figure out the right phrases to search — what I want is one thing. Tell me exactly what style is winning so I can defeat it. Tell me exactly where it’s coming from.
That’s what DevTools can show you, if you know how to read it. The Styles panel in DevTools will display the rules applying to an element, including the ones that lost, which show up with a strikethrough. If you click on your element and scan the Styles panel, you’re looking for a rule with border: none or border-width: 0 that sits above your rule — meaning it has higher specificity or came from a more specific selector. The source file name is listed next to each rule, which tells you where it came from.
The difficulty is reading it. The panel stacks rules from multiple sources and you have to understand which ones are winning and why. If you’re fluent in that panel, you’ll find it. If you’re not, it’s noise.
If you want the cascade read for you in real human terms, Loupely Lens does exactly that: click on the element with the missing border, and Lens reads the full CSS picture behind it, identifies which rule is winning and where it came from, and tells you what to do next. No cascade to interpret yourself.
The special hell of plugin output
I want to name this specifically, because if the border that disappeared is on an element rendered by a plugin — a product listing, a knowledge base sidebar, a booking widget, a form — you’re dealing with a harder version of the problem.
There’s a special hell in customizing the output that comes from WordPress plugins, because it never fully clicks how the plugins and the theme and your changes are interacting. The plugin has its own stylesheet. The theme has its own rules. Your custom CSS is in a third place. And none of these three sources knows about the others. When a border disappears on plugin-rendered output, the rule overriding it could be living in any of those three places, and finding it feels like stabbing in the dark. You try everything you can try, put in all your effort, and nothing changes. Not because the fix doesn’t exist, but because you can’t see where the conflict is coming from.
The approach that actually works: find the specific rule that’s winning, figure out what stylesheet it lives in, and write a rule that beats it. Sometimes that means a more specific selector. Sometimes it means targeting the element by its generated class name. Sometimes it means !important, though that comes with its own consequences. But none of that can happen until you know which rule you’re trying to defeat.
For CSS failures on plugin output specifically, the post on CSS override not working covers the full diagnostic sequence, and the post on CSS button wrong color works through the same cascade conflict with a different symptom — the structure of the problem is identical.
What to actually do
When your CSS border isn’t showing, the path forward is the same regardless of the platform:
Open DevTools (right-click the element, choose Inspect). In the Styles panel on the right, look for any rule with border: none, border-width: 0, or border-color: transparent that has a higher position in the stack than your rule. The source of that rule — the stylesheet filename — tells you where it came from. If it’s from a plugin or theme file, you need a rule that targets the same element with higher specificity than the one overriding you.
Also check: is the border color set to something that matches your background? And is the element’s height constrained in a way that might be squeezing the border out of view?
When a border disappears, something specific is causing it — a rule that’s winning, a color that’s invisible, a dimension that’s too tight. The border failure isn’t the problem. The missing visibility is. Once you can see which rule is winning, you know exactly what to change.
Open DevTools now, click on the element with the missing border, and look at the Styles panel. Find the rule with border: none that’s sitting above yours. That’s where to start.