CSS Validator
Check CSS structure locally with line-aware errors and review warnings for duplicate declarations, empty rules, and risky at-rules.{{ summaryTitle }}
{{ summaryLine }}
| Location | Rule | Severity | Finding | Next action | Copy |
|---|---|---|---|---|---|
| L{{ finding.line }}:C{{ finding.column }} | {{ finding.rule }}{{ finding.alias }} | {{ finding.severity }} | {{ finding.description }}{{ finding.detail }}{{ finding.context }} |
{{ finding.action }} | |
| No findings in the selected scope.This does not prove browser support or universal CSS conformance. | |||||
The chart renderer is unavailable. The finding ledger and fix plan remain available.
Fix plan
{{ section.title }}
{{ section.body }}
{{ fixPlanCopyAnnouncement }}
A browser can display a page even when part of its stylesheet is malformed. CSS parsing is deliberately forgiving: an invalid declaration or rule may be discarded while the rest continues to apply. That recovery is useful for the web, but it can hide a typo behind inherited styles, cached assets, or a fallback declaration until the same CSS reaches another page or build step.
Structural validation focuses on the grammar that holds a stylesheet together. Quotes and comments need closing delimiters, parentheses and braces must balance, declarations need a property name, colon, and value, and qualified rules need a selector followed by a block. These checks answer a narrower question than visual testing.
| Review | What it can reveal | What it cannot prove |
|---|---|---|
| Structural syntax | Broken strings, comments, delimiters, declarations, and rule blocks | How a selector matches the page or how the cascade resolves |
| Bounded code review | Duplicate declarations, empty blocks, !important, and at-rules that need confirmation | That a warning is always a defect |
| Browser testing | Rendering, feature support, layout, interaction states, and fallback behavior | That every source rule is well formed or maintainable |
| Project tooling | Repository conventions, preprocessors, frameworks, compatibility targets, and lint policy | Universal CSS conformance outside that project |
Modern CSS makes simple keyword lists unreliable. Custom properties can contain broad token sequences, nesting places rules inside rules, and new at-rules appear as the language evolves. A rule set limited to old property names or flat blocks can create more noise than useful evidence. Structural checks should therefore distinguish definite grammar failures from review warnings about supported subsets.
A clean result is a good point to begin browser and project testing, not a certificate that the stylesheet will look the same everywhere. Test the affected states at the target viewport sizes, with the real HTML, fonts, assets, and browser matrix before treating a visual change as complete.
How to Use This Tool:
Start with structural syntax, then add review warnings only when you are ready to judge the cascade and project intent.
- Choose Structural syntax for definite grammar checks, or Syntax + bounded review rules to also flag duplicate declarations, empty rules,
!important, and unrecognized at-rules. - Paste one stylesheet into Stylesheet or load a local CSS or text file. The source must stay within 200,000 characters and 5,000 lines.
- Read errors in source order and fix the first structural problem before later ones. One missing brace can change how the rest of the stylesheet is grouped, so recheck after each structural repair.
- Review warnings rather than deleting them automatically, then test the edited stylesheet with the actual page and target browsers. A repeated property may be an intentional fallback,
!importantmay be necessary, and an unfamiliar at-rule may belong to a newer standard or build tool. Showing source context changes only the finding display.
Interpreting Results:
Errors identify supported structural failures such as an unclosed comment, mismatched delimiter, missing declaration colon or value, invalid property name, or top-level statement without a rule block. Use the line and column to repair the source, then validate again because one fix can remove several later symptoms.
Warnings are review prompts from the broader profile. They do not mean that the stylesheet is invalid. Confirm each duplicate declaration, empty rule, !important flag, or unrecognized at-rule against the intended cascade, browser support, and build process.
No findings means the bounded rules did not detect a problem. It does not test selector matching, computed styles, layout, animation, accessibility, URL loading, imported stylesheets, browser compatibility, or framework conventions. A real page render remains the corrective check for false confidence.
Technical Details:
CSS syntax is token-oriented and error tolerant. A useful local check must ignore delimiter-like characters inside comments and quoted strings, preserve custom-property values, and recognize rule-list at-rules before deciding whether a brace starts nested rules or declarations. The source is analyzed as inert text and is not rendered or rewritten.
Rule Core
The validator applies ordered structural checks first. The optional review profile adds warnings only after the same source structure has been identified.
| Stage | Rule | Finding |
|---|---|---|
| Source bounds | Require non-blank text no longer than 200,000 characters or 5,000 lines. | Input issue; structural analysis does not run |
| Strings and comments | Mask complete quoted strings and comments while reporting unterminated ones and null code points. | Error at the opening or offending character |
| Delimiters | Match parentheses, square brackets, and braces in nesting order. | Unexpected, mismatched, or unclosed delimiter error |
| Declarations | Require a supported property identifier, colon, and non-empty value inside declaration blocks. | Missing colon, invalid name, or missing value error |
| Rules | Require a selector or at-rule prelude before a block and a block after top-level qualified-rule text. | Missing prelude or missing rule-block error |
| Review profile | Within each block, flag repeated property names, empty rule blocks, !important, and at-rules outside the recognized set. | Warning requiring project or platform judgment |
At-rules change how their blocks should be read. Grouping rules such as @media, @supports, @layer, and @container contain rule lists. Declaration-oriented rules such as @font-face, @page, and @property contain declaration blocks. Keyframe rules contain nested rule blocks. This distinction prevents valid nested structure from being mistaken for a malformed declaration.
Quoted content and comments are replaced with spacing for structural analysis while line breaks and offsets are preserved. That keeps a brace inside a string or comment from changing delimiter depth, yet still allows line- and column-aware findings against the original source.
| Limit | Maximum | Effect |
|---|---|---|
| Source characters | 200,000 | Larger source is rejected before analysis. |
| Source lines | 5,000 | Larger source is rejected before analysis. |
| Findings | 250 | Additional findings are omitted and the result is marked truncated. |
The analysis does not fetch @import targets, fonts, images, source maps, or URLs. It also does not maintain a complete property-value grammar for every CSS module. That boundary is why structural failures are errors while unfamiliar at-rules in the review profile remain warnings.
References:
- CSS Syntax Module Level 3, W3C, 24 December 2021.
- CSS Nesting Module Level 1, W3C Working Draft, 22 January 2026.