{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Errors {{ resultsReady ? computation.values.error_count : '—' }} Warnings {{ resultsReady ? computation.values.warning_count : '—' }} Source {{ resultsReady ? 'Preserved' : 'Waiting' }}
CSS validation inputs
Neither profile tests browser support, rendering, or project-specific conventions.
Paste one stylesheet or load one local .css or text file up to 200 KB.
{{ sourceMeta }}
{{ fileStatus || 'Drop one CSS or text file onto the editor.' }}
The neutral default is off. Enabling it adds the affected source line without changing validation.
CSS findings ordered by source line, column, and rule id
LocationRuleSeverityFindingNext actionCopy
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.
{{ tableExportStatus }}
{{ chartExportStatus }}

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.

CSS review layers and the questions they answer
Review What it can reveal What it cannot prove
Structural syntaxBroken strings, comments, delimiters, declarations, and rule blocksHow a selector matches the page or how the cascade resolves
Bounded code reviewDuplicate declarations, empty blocks, !important, and at-rules that need confirmationThat a warning is always a defect
Browser testingRendering, feature support, layout, interaction states, and fallback behaviorThat every source rule is well formed or maintainable
Project toolingRepository conventions, preprocessors, frameworks, compatibility targets, and lint policyUniversal 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.

  1. Choose Structural syntax for definite grammar checks, or Syntax + bounded review rules to also flag duplicate declarations, empty rules, !important, and unrecognized at-rules.
  2. 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.
  3. 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.
  4. 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, !important may 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.

CSS structural and review rule groups
Stage Rule Finding
Source boundsRequire non-blank text no longer than 200,000 characters or 5,000 lines.Input issue; structural analysis does not run
Strings and commentsMask complete quoted strings and comments while reporting unterminated ones and null code points.Error at the opening or offending character
DelimitersMatch parentheses, square brackets, and braces in nesting order.Unexpected, mismatched, or unclosed delimiter error
DeclarationsRequire a supported property identifier, colon, and non-empty value inside declaration blocks.Missing colon, invalid name, or missing value error
RulesRequire 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 profileWithin 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.

CSS validation limits
Limit Maximum Effect
Source characters200,000Larger source is rejected before analysis.
Source lines5,000Larger source is rejected before analysis.
Findings250Additional 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: