Fixing CSS Validation Errors

What the browser does with bad CSS

CSS parsers are built to keep going. The specification defines exactly how a browser recovers from each kind of mistake, and the recovery is always to discard something and carry on. How much gets discarded depends on where the mistake is:

None of these produce a console error. The only way to see them is to validate the file, lint it, or notice that something on the page looks wrong and inspect it. That is why validation errors often survive for years: the page looks almost right, and the rule that failed was for a state nobody tested, such as a focus outline or a narrow screen.

Finding the errors

Validate what the browser receives

Run the CSS Checker on your pages. It validates the CSS against W3C standards alongside its other checks, so you see validation errors in the context of the stylesheets each page loads. For a single file, the W3C CSS Validation Service accepts a URL, an upload or pasted CSS, and has options for the CSS profile and for how vendor-prefixed properties are reported.

Validate the served output as well as your source files. A preprocessor, minifier or plugin can introduce errors that are not in the file you edit, and an error in the source may already have been removed by the build.

Use the browser's Styles pane

In Chrome, Edge or Firefox, inspect the element that looks wrong. Declarations the browser rejected are shown crossed out with a warning icon; hover the icon to see whether the problem is an invalid value or an unknown property name. This is the quickest way to confirm that an error you found actually affects a visible element.

Lint the source

Stylelint reads your source CSS, SCSS or Less and reports errors with the file and line. A minimal setup:

npm install --save-dev stylelint stylelint-config-standard
echo '{ "extends": "stylelint-config-standard" }' > .stylelintrc.json
npx stylelint "src/**/*.css"

Rules such as property-no-unknown, selector-pseudo-class-no-unknown, unit-no-unknown, color-no-invalid-hex, no-invalid-double-slash-comments and declaration-block-no-duplicate-properties catch most of the errors in this guide before they ever reach the browser.

The fix, step by step

Common errors with corrected code

These examples come from a fictional site, Oakfield Dental, and show the error as written and the corrected version.

/* Before */
.hero {
  padding: 24 16px;              /* unitless non-zero length */
  colour: #1d3557;               /* British spelling is not a CSS property */
  background: #f1faee
  border-radius: 8px;            /* missing semicolon on the line above */
}
// Primary buttons              /* not a CSS comment */
.btn, .btn:hovr { color: #fff; } /* one bad pseudo-class drops both */
@media (max-width: 40em) {
  .nav { display: none;          /* missing closing brace for this rule */
}
.footer { font-family: “Inter”, sans-serif; } /* curly quotes */

/* After */
.hero {
  padding: 24px 16px;
  color: #1d3557;
  background: #f1faee;
  border-radius: 8px;
}
/* Primary buttons */
.btn { color: #fff; }
.btn:hover { color: #fff; }
@media (max-width: 40em) {
  .nav { display: none; }
}
.footer { font-family: "Inter", sans-serif; }

Errors from preprocessors

• Sass division. In current Dart Sass, a slash is no longer treated as division in most cases. Code such as $gap / 2 is flagged by the compiler, and the output may contain a literal slash that is invalid for that property. Use math.div() or calc().
• Unescaped interpolation. Building a selector or value from variables can leave empty strings or stray characters. Validate the compiled CSS, not just the Sass.
• Nested media queries in Less or Sass. These compile correctly, but an unclosed brace in a nested block can produce output where large parts of the file end up inside one media query.

When the validator is wrong

The W3C validator is a helpful tool but not the final word. It checks your CSS against the specifications it knows, and new features can reach browsers before the validator recognises them. Features that have been reported as unknown at various times include container queries, cascade layers, native nesting, :has(), colour functions such as color-mix() and light-dark(), and newer units. Support improves over time, so re-test before assuming a message is a false alarm.

To decide quickly:

1. Look up the feature on MDN or Can I Use and check that it is supported in the browsers your visitors use.
2. Confirm in the browser's Styles pane that the declaration is not crossed out.
3. If both are fine, the message is validator lag. Leave the code alone, and add a comment if it will confuse the next person to validate the file.

Custom properties are another source of confusion. The validator cannot know what a variable will contain, so a value such as margin: var(--space) is accepted even if --space holds something invalid. Those errors only show up in the browser, as a declaration that falls back to its initial or inherited value.

Platform notes

WordPress

Errors often come from the Additional CSS box in the Customizer or from page builder custom CSS fields, which do little or no checking. Copy the contents into a validator before and after editing. Errors in a plugin's stylesheet should be reported to its developer; overriding them from a child theme only hides the symptom. See the WordPress CSS guide.

Shopify

Theme editor Custom CSS fields reject some input when you save, but an error in an asset file will only show on the storefront. Validate custom.css and any edited theme assets. See the Shopify CSS guide.

Build pipelines

Add Stylelint to the same place you run tests. Some minifiers repair or drop invalid declarations silently, which hides the problem in production but leaves it in your source, so lint before the minifier runs.

Stopping validation errors coming back

• Enable CSS validation in your code editor; most editors underline unknown properties and unclosed braces as you type.
• Run Stylelint in a pre-commit hook and in CI, with the configuration checked into the project.
• Treat CSS pasted from tutorials, AI tools or word processors as untested; paste it through a validator first.
• After fixing errors, check browser-prefix coverage and specificity conflicts, since both often surface once rules start applying again.
• Re-run the CSS Checker after each theme, plugin or app update.