Why is height:100% not working when set on a div in CSS?

When you set height:100% on a div in CSS and it still doesn't take effect, the root cause is almost always that the containing block height isn't defined, not that the style is wrong. In 2026, when working on design-to-code projects, most issues like this can be found in the parent height chain. height:100% isn't meant to fill the viewport; it fills a parent that already has a defined height. When the parent height is auto, the browser treats height:100% as auto, which makes it look like nothing happened.

Why is height:100% not working? Check the containing block height first

Percentage heights first need a parent height, then they are calculated proportionally. A block-level parent element's default height is determined by its content, so its computed value is usually auto; in that case, the child's 100% has no reference number. Even if the parent is given min-height:100vh, it is not a definite height for the child either, because min-height only constrains the minimum box height and cannot be used as a reference for percentage heights. So height:100% still doesn't work.

In 2026 projects, common mistakes usually fall into these three categories:

• The parent only sets min-height, so child height:100% has no fixed reference value.
• Writing height:100% hard-coded in a flex or grid container — children may already be stretched by default, and adding 100% can cause overflow or clipping.
• After absolute positioning, the containing block becomes the nearest positioned ancestor, not the visually adjacent parent box.

The checking method is direct: look up the ancestor chain from the target element. Every ancestor's height must have a numeric or computable value for height:100% to truly take effect. But not every page requires writing the parent chain all the way down. First eliminate what doesn't apply, and you will avoid rewriting a pile of invalid styles.

Before changing styles: what this method applies to and what it doesn't

height:100% suits scenarios where the parent height is explicit and children need to follow it, such as the content area of an admin layout framework, fixed-height card areas, or layouts inside iframe-embedded pages. For these pages, as long as html, body, and outer containers are connected layer by layer, height:100% is predictable.

But it is not recommended in these scenarios:

• When the parent height is content-driven, such as accordions, comment lists, or chat records; height:100% has no reference, and adding overflow can easily produce double scrollbars.
• When you need a full-page background to cover the viewport; use viewport units or flex instead of giving a child height:100%.
• When you need to fill remaining space inside flex/grid; prefer flex:1 + min-height:0. height:100% tends to fight with the stretch rule.

Once the boundary is clear, the approach becomes much clearer: if the parent height is pushed out by content, height:100% has no meaning at that level. Use viewport units to cover the viewport, use flex for remaining space, and leave height:100% for cases where the parent already has a fixed height.

Debug along the three-level chain: viewport, container, and self

When locating the issue, checking the three-level chain is faster than trial-and-error style changes. The browser needs the height chain to be connected; if any intermediate layer is auto, the percentage above it is cleared.

1. Viewport: Open DevTools and check the computed heights of html and body. Only when both are set to 100% is the viewport height passed down; if only one is set, the chain may break.
2. Container: Check whether the computed height of the target element's parent is a number or auto. If you temporarily set the parent to height:300px and the child immediately turns to 300px, the break is here.
3. Self: Check whether the target element is disturbed by absolute positioning, floats, or flex stretching. Also check whether box-sizing, margin, and padding leave less actual space than expected.

Here is an example from a real delivery: I once received a campaign page where the footer did not stick to the bottom when content was shorter than a viewport, and the outer template required keeping structural changes minimal (constraint). So I only added the height chain to the outermost container, changed the middle content area to flex, and used flex:1 on it to absorb the remaining space. It passed desktop on the first attempt. Later, the mobile address bar collapsed and exposed white space at the bottom, so I used 100dvh as a fallback and did a regression. Overall, it took about 0.5–1 working day more (result and trade-off).

Based on experience from design-to-code projects, issues caused by html/body not being fully set usually take 5–10 minutes to locate; for legacy templates with several auto layers in between, the experience range is 10–30 minutes; for projects that need a complete height-chain refactor plus a mobile regression, the typical range is 0.5–1 working day. This time range is not a commitment, but a reference for estimating rework scope.

How to choose between height:100%, 100vh, 100dvh, and flex:1: comparison and experience ranges

Even when the goal is to fill up the available space, different scenarios need different solutions. Here is a comparable overview for quick decisions in solution reviews or code reviews.

• height:100%: suited to internal areas whose parent height is already fixed, such as the content area in an admin system. The change usually takes only one or two lines, with a typical development effort of 5–15 minutes; once the parent becomes auto, this style will fail in later iterations.
• min-height:100vh: suited to making the background cover the viewport when content is shorter than one screen. Modern browser compatibility is fairly stable. A single-page adjustment usually takes 10–30 minutes; on mobile, the dynamic address bar may reveal white space when collapsed, so a real-device check is needed.
• min-height:100dvh: a dynamic viewport unit, better suited to full-screen mobile pages. In production, it is recommended to write 100vh first and then override with 100dvh, and run a regression across common browsers. Real-device verification plus regression to fix differences usually adds about 0.5 working day.
• flex:1 + min-height:0: suited to containers that need to take remaining space, such as sidebars and chat windows. The parent must be flex and have a definite height or min-height. Adding min-height:0 to children prevents overflow, and maintainability is usually better than layering height:100% level by level.

These effort estimates are experience ranges from design-to-code projects, not precise quotes. Key takeaway: min-height cannot serve as a reference for a child's percentage height. Use viewport units when you need to fill the viewport, use flex when you need to fill remaining space, and use height:100% only when the parent height is explicit.

For acceptance testing, temporarily set a fixed height on the parent. If the child follows immediately, the chain is connected. When content is too long and needs internal scrolling, use flex children with min-height:0 instead of nested height:100% plus overflow, which will save you from the double-scrollbar pitfall.

FAQ

Which is more reliable, height:100% or height:100vh?

When the parent height is explicit, height:100% is more reliable because it follows the parent container. 100vh uses the viewport directly and is mainly for full-screen positioning. The mobile address bar dynamically collapses, so write 100vh first and override with 100dvh.

If the parent element doesn't have a height, how does a child fill remaining space?

Enable flex on the parent, set the child to flex:1, and add min-height:0. Then the child occupies the remaining space, which is more stable than writing height:100% on every level. When the parent height is not fixed, height:100% has no reference value anyway.

When DevTools shows height:100% or auto, where should I look first?

Follow the three steps: viewport, container, and self. First check whether html and body both have 100%; then check the parent's computed height; finally check whether the target element is affected by positioning or flex. Temporarily set the parent to a fixed height, and you can quickly locate the layer where the chain breaks.

Why doesn't height:100% work when hard-coded inside a flex container?

Flex children are stretched by default, and the actual height is decided by the flex algorithm. height:100% may not calculate against the parent's normal content area. Instead, use flex properties and min-height:0 to control the size, rather than adding more height:100% levels.

Overall, height:100% is not a universal solution. It is best for scenarios where the containing block has an explicit height. When building pages in 2026, first draw a clear boundary of applicable cases, then check along the three-level viewport–container–self chain. Most height problems can be solved without taking detours. The effort values in this article are project experience ranges; actual estimates must include the template complexity and the mobile regression scope.