Every front-end developer hits this at some point. You slap hidden onto an element, refresh the page, and the element is still sitting right there, fully visible. The attribute is valid HTML, the browser supports it, and yet nothing happens. I've debugged this enough times to know there are really only three culprits: a CSS display rule, a cascade fight, or a framework doing something behind your back.
First, understand what hidden actually does
The hidden attribute is a boolean attribute. Its presence alone hides an element — the value is irrelevant. Browsers implement it with a single rule in the user-agent stylesheet:
[hidden] { display: none; }
That one line explains nearly every failure you'll encounter. User-agent stylesheet rules sit at the bottom of the cascade. Any CSS you write — even a plain class selector — beats it, regardless of specificity. So the attribute isn't "broken." It's losing a fight it was never equipped to win.
Cause 1: A display rule is overriding it
This is the big one, and it's the reason I put a small reset in every project's base stylesheet. Picture a card component:
.card { display: flex; gap: 1rem; }
Add hidden to that card and it stays visible. The class selector comes from the author stylesheet, the hidden rule comes from the browser, and author styles always win at the same importance level. Specificity never even gets a chance to matter.
The fix is a one-liner:
[hidden] { display: none !important; }
Yes, !important. Normally I'd tell you to avoid it, but this is one of the few places where it's genuinely appropriate: the rule has exactly one job, it's scoped to a single attribute, and it encodes the HTML spec's intent. Drop it into your reset or base layer and the attribute becomes reliable across the whole project.
One modern wrinkle: if you use hidden="until-found" — the value that lets browsers find hidden content via in-page search and expand it — a blanket display:none !important will break it, because until-found relies on content-visibility rather than display. The spec-recommended version handles both:
[hidden]:not([hidden="until-found"]) { display: none !important; }
If you never use until-found, the simpler rule is fine.
Cause 2: Specificity wars and inline styles
Sometimes the override is more deliberate. A few patterns I run into regularly:
- Inline styles. If an element carries style="display: block" — set by earlier JS, a third-party widget, or an animation library — that inline declaration beats every stylesheet rule you have. Adding hidden does nothing.
- Overzealous component CSS. I've inherited stylesheets containing .modal[hidden] { display: flex !important; } left over from some past refactor. That !important defeats your reset, and now two "fixes" are fighting each other.
- Utility-class confusion. In Tailwind, the hidden class and the hidden attribute are completely different things. A teammate's class="flex" on the same element will override the attribute unless you've added the reset above. Mixing the two mechanisms on one element is a recipe for confusion.
The debugging move here is DevTools, not guesswork. Inspect the element, open the Computed tab, and look at the display property. If it's anything other than none, click through to the Styles pane — Chrome and Firefox both show you exactly which rule won and which got crossed out. Then fix the actual winner. If it's an inline style, remove the style rather than piling on more CSS:
el.style.removeProperty('display');
Setting the hidden attribute from JavaScript does not clear an inline display style. That mismatch trips people up constantly.
Cause 3: Framework re-renders undoing your work
Modern frameworks add their own twists.
React
React handles hidden as a normal attribute, but watch the value you pass. Writing hidden={isHidden ? 'true' : 'false'} looks reasonable and is completely wrong: the string "false" is still a present attribute, so the element stays hidden in both branches. Presence is what counts, not the value. Either pass a real boolean — hidden={isHidden} — or use conditional rendering with && when you want the element gone from the DOM entirely.
The second React gotcha: libraries that manipulate style.display directly. I once fought a draggable-list library that stamped display: block onto items mid-drag. React faithfully re-applied the hidden attribute on every re-render, but the inline style from the library survived and won. When two systems control visibility, the inline style usually wins. Pick one owner.
Vue
Vue's v-show directive works by toggling an inline display: none. Mixing it with the hidden attribute on the same element means two mechanisms racing each other — when v-show flips to visible, it removes the inline style, and if the element also carries hidden plus a display: flex rule, it pops right back. Also remember to bind: writing hidden="{{expr}}" in a template sets a literal string attribute instead of a reactive one. Use :hidden="expr".
SSR and hydration
If your server renders hidden but client hydration removes or re-evaluates it, you get a flash of content that then vanishes — or worse, content that should be hidden and never is. Always check the rendered DOM in the Elements panel, not your source code. What the server sent and what the client ended up with are often not the same thing.
A five-minute debugging routine
When hidden fails, work through this in order. It resolves the issue for me almost every time:
- Inspect the element and open the Computed tab. What is display?
- If it's not none, check the Styles pane for the winning rule — inline style, class, or a stray [hidden] rule.
- Look at the element in the Elements panel. Is the attribute actually present in the rendered DOM? Frameworks strip or rewrite attributes more often than you'd expect.
- Check the value. hidden="false" still hides. hidden="until-found" behaves differently on purpose.
- Search your codebase for [hidden] selectors. Somebody may have added a conflicting rule months ago.
Know when hidden is the wrong tool
Even working perfectly, hidden isn't always the right choice:
- You need a transition. display: none skips transitions entirely, so the element just snaps. Toggle a class instead, or look at the newer transition-behavior: allow-discrete and @starting-style if you can target modern browsers.
- You need it visually hidden but available to screen readers. hidden removes the element from the accessibility tree completely. For visually-hidden-but-accessible content, use the classic visually-hidden CSS pattern instead.
- Visibility changes constantly. Conditional rendering (v-if, JSX conditionals) gives you cleaner lifecycle hooks than an attribute you keep flipping.
Most hidden failures come down to that user-agent stylesheet rule losing the cascade. Add the [hidden] reset once, keep a single source of truth for visibility in your components, and this bug stops showing up. It's a five-minute fix for a problem that routinely eats an entire afternoon.