How this CSS validator works
This CSS validator checks your stylesheet in two passes. First it parses the file with PostCSS, which finds syntax errors: unclosed blocks, stray braces, unclosed strings or comments. If the syntax is valid, a second pass uses the CSS grammar data from the csso project to check each declaration: is the property known, and does the value match what the specification allows for it? The report lists every problem with its line and column, plus the number of rules and declarations checked.
Example
.card{colr:red;display:flexbox;margin:10px 5px 3px 2px 1px;--brand:#0f766e;-webkit-box-flex:1;width:calc(100% - 20px)}Syntax is valid, but 3 problem(s) were found:
Line 1, column 7: Unknown property "colr"
Line 1, column 16: Invalid value for "display": flexbox
Line 1, column 32: Invalid value for "margin": 10px 5px 3px 2px 1px
Rules: 1
Declarations: 6colr is a typo. flexbox is not a valid display keyword (you want flex). margin accepts one to four values, not five. The custom property, the vendor-prefixed -webkit-box-flex and the calc() width pass.
Why invalid CSS is a silent problem
Browsers are designed to be forgiving with CSS: when a declaration is invalid, it is simply ignored, and the rest of the rule still applies. That is good for users but bad for debugging, because nothing tells you that display: flexbox did nothing. A syntax error is worse: a missing } can make the browser treat the following rules as part of the broken block, so styles far away from the mistake stop working. A validator catches both before they reach production.
What is checked
- Syntax: balanced braces, closed strings and comments, well-formed at-rules, and no stray characters. Syntax errors are reported first and stop the check.
- Unknown properties: misspellings and properties that do not exist in any CSS specification.
- Invalid values: wrong keywords, wrong number of values, invalid units or colors.
Some declarations are deliberately skipped because they cannot be checked against the standard grammar: custom properties (--name), vendor-prefixed properties (-webkit-, -moz-), and old IE hacks such as *zoom and _height.
Common errors and fixes
| Report | Typical fix |
|---|---|
| Unclosed block | Add the missing }; the position points to where the unclosed block starts |
| Unexpected } | Remove an extra closing brace |
| Unknown property "text-colour" | Use US spelling: color, text-decoration-color |
| Invalid value for "width": 100 | Add a unit: 100px. Only 0 may be unitless for lengths |
| Invalid value for "color": #ggg | Hex colors use 0–9 and a–f, with 3, 4, 6 or 8 digits |
Limits of automated validation
The property and value data covers the CSS specifications broadly, but very new features can arrive in browsers before validator data catches up, so a recently shipped property may be reported as unknown even though your target browsers support it. At present that affects oklch() and color-mix() colors and the container-type and text-wrap properties. Declarations inside nested rules (CSS nesting) are not checked at all, so a typo there is not reported. Also, "valid" does not mean "supported everywhere": check browser support tables for newer features. SCSS and LESS syntax such as $variables or mixins is not plain CSS; compile it first with the SCSS Compiler and validate the output.
After validating, make the file readable with the CSS Formatter or smaller with the CSS Minifier. Validation runs in your browser; your stylesheet is not uploaded.