CSS calc() Not Working — Every Cause and Fix With Code Examples

The CSS parser processes calc() expressions with stricter rules than most developers expect. Unlike JavaScript arithmetic, CSS calc() has type constraints built into the spec. A length divided by another length would produce a dimensionless number, not a length, which means it cannot be used as a width or height. The browser enforces this at parse time by rejecting the entire declaration, not by displaying an error.

The spaces-around-operators rule is the most frequent trap. The spec requires whitespace before and after + and - operators specifically because these characters can appear at the start of a number as a sign. Without spaces, calc(100%-20px) is parsed as a single custom-ident token, and the parser cannot interpret it as subtraction. The result is that the entire property declaration is treated as invalid and silently dropped.

Mixing units in calc() is intentional and powerful: calc(100vw - 2rem) is valid because the browser defers the pixel resolution of both the vw and rem values to computed time, when it knows the viewport width and the root font size. However, multiplying two dimensional values is not allowed: calc(2rem * 1px) is invalid because the type would be length-squared, not length.

Custom properties add another layer of complexity. A var() reference inside calc() is not resolved at parse time — it is resolved at computed value time. If the custom property is undefined, the entire expression becomes the guaranteed-invalid value and the browser acts as if the declaration does not exist. Unlike a syntax error (which the browser skips and continues), an invalid computed value can cascade: other properties that inherit from this value may also fail.

Open DevTools and select the element. In the Styles panel, look for the property where you used calc(). If the property name has a yellow warning icon or a strikethrough, the declaration is invalid. Hover over the warning to see a tooltip with the parse failure reason. In Chrome 119 and later, the tooltip may identify the specific token that failed.

In the Computed tab, look for the property you expected calc() to set. If it shows the initial value — for example, width showing auto when you expected a pixel value — the declaration was rejected. If it shows a value but not the one you expected, the expression parsed correctly but evaluated to a different result, often because a custom property resolved to an unexpected value.

To debug a calc() that references var(), add a temporary rule that declares each custom property directly on the element and check whether the layout changes. For example, add --sidebar-width: 260px inline on the element via DevTools and see if the width updates. If it does, the original custom property was undefined or scoped incorrectly. Search the Computed tab for the custom property name to find its resolved value at the element.

For complex nested expressions, simplify step by step. Replace calc((100% - var(--gap) * 3) / 4) with calc(100% / 4) first to confirm the basic structure works, then add back the subtraction. This isolates whether the division, the custom property reference, or the parenthesization is the cause of the failure.

For missing spaces, add whitespace around all + and - operators. A quick way to catch this in your editor is to search the project for the pattern calc(.*[+\-]) and review every match for missing spaces. CSS linting tools including stylelint can enforce calc() spacing automatically on save, which catches the error before it ever reaches the browser.

For division errors, always check whether your divisor has a unit. If you are calculating a column width for a grid, you almost always want to divide by a plain number: calc((100% - 48px) / 3) for three columns with a total gap of 48px. If you find yourself wanting to divide by a px value, reconsider the math — you almost certainly want a unitless ratio, and CSS Grid's fr unit may eliminate the need for calc() entirely.

For custom property issues, add fallback values to every var() that appears inside a calc() expression. The syntax is var(--my-property, fallback-value). The fallback documents the intended type and scale of the variable, which helps other developers understand what value is expected. If the fallback is another var() call, wrap it in parentheses: var(--primary, var(--secondary, 1rem)).

For calc() inside media queries, you cannot use custom properties as breakpoint values. The spec prohibits var() inside media query conditions because custom properties are resolved per-element in the computed value cascade, but media queries are evaluated before any element exists in the tree. If you need responsive breakpoints driven by design tokens, use a CSS preprocessor variable that resolves at build time, or use Container Queries which operate on an element's available space rather than the viewport.

Nested calc() expressions are valid: calc(calc(100% - 20px) / 3) is allowed and equivalent to calc((100% - 20px) / 3). Modern browsers resolve the inner calc() first and then apply the outer operation. The nested form is redundant but not harmful. If you are using a CSS preprocessor that generates nested calc() from mixins, the output is valid and you do not need to collapse it manually.

The min(), max(), and clamp() functions accept calc() expressions as their arguments and are often better choices for responsive values. clamp(1rem, 2.5vw, 1.5rem) sets a font size that is fluid between viewport widths and bounded by fixed minimum and maximum values without any calc() arithmetic. For cases where you need to add a fixed offset to a fluid value, clamp() and calc() compose naturally: clamp(200px, calc(50% + 20px), 600px) is valid and well-supported.

Inside SVG, calc() is not supported in presentation attributes such as width, height, x, and y. These attributes accept a CSS length string in modern SVG 2, but the browser's SVG attribute parser does not run the full CSS calc() engine. If you are using inline SVG and need responsive dimensions, set the width and height via CSS classes on the SVG element rather than through presentation attributes, or use the SVG viewBox attribute with percentage-based layout instead.

In older versions of Safari (before Safari 15), calc() inside a CSS custom property declaration had limited support. A pattern like :root { --total-width: calc(100vw - 2rem); } might resolve to zero on Safari 14. The practical fix is to store static values in custom properties and apply calc() at the usage site: width: calc(var(--content-width) - var(--sidebar-width)) rather than storing the calc() result in the custom property.

Copying calc() expressions from Figma or design tool exports is a reliable source of space-missing bugs. Design tools often format values without spaces — 100%-20px looks clean in a properties panel but fails in CSS. Always add spaces when pasting from any source, and run the output through a CSS formatter to validate the syntax before committing.

Applying calc() to properties that CSS layout algorithms already handle natively adds unnecessary complexity. width: calc(100% / 3) for a three-column layout is correct but verbose compared to display: grid; grid-template-columns: repeat(3, 1fr). Reserve calc() for values where the layout system cannot do the arithmetic for you, such as subtracting a fixed sidebar width from a fluid container width.

Writing calc(0px + var(--offset)) to force a unit on a unitless custom property is a known workaround that works but is fragile. When a custom property holds a plain number (--multiplier: 2), you cannot use it directly in a length context. The workaround calc(1px * var(--multiplier)) produces a valid length. However, the cleaner solution is to store the value with its unit in the custom property from the start: --multiplier: 2px avoids the workaround entirely.

Failing to test calc() in Firefox and Safari after testing only in Chrome is a common oversight. While the spec is clear on operator spaces and unit rules, edge cases with nested expressions and custom property interactions have historically differed between rendering engines. Add a Firefox and Safari check to your browser testing matrix before shipping any complex calc() expression, especially if it uses nested var() references or clamp().

Always write calc() with explicit spaces around + and -. Even if your linter does not enforce it yet, the habit eliminates an entire class of silent parse errors. Many teams add a stylelint rule for this as part of their CSS linting configuration, which catches the error at commit time rather than after deployment to a staging environment.

Prefer named custom properties over magic numbers inside calc(). Instead of calc(100% - 260px), write calc(100% - var(--sidebar-width)) and declare --sidebar-width: 260px in a central token file. This makes the intent explicit, allows the value to be overridden at any scope level, and makes responsive adjustments (changing --sidebar-width in a breakpoint) straightforward and contained.

Use clamp() for responsive values that have natural minimum and maximum bounds. font-size: clamp(1rem, 2vw + 0.5rem, 1.5rem) is a fluid type scale with clamped extremes, and it is cleaner than a calc() expression nested inside min() inside max(). The clamp(min, preferred, max) pattern is supported in all modern browsers without prefixes since 2020 and should be the default choice for fluid sizing.

Document complex calc() expressions with a short comment explaining the math. A comment like /* (full width minus 3 gaps of 16px) divided by 4 columns */ above calc((100% - 48px) / 4) makes the expression immediately readable to anyone who encounters it. The comment adds no runtime cost and significantly reduces the time needed to debug or adjust the expression when requirements change.

When migrating older calc() patterns to modern CSS, consider adopting clamp() as the primary tool for responsive sizing. The clamp(min, preferred, max) syntax expresses the intent of a value more clearly than nested calc() with min() and max() wrappers, and it composes naturally with viewport units and rem values in the preferred expression, making fluid typography and spacing systems easier to read and maintain.