CSS Validator

Most languages tell you when you have made a mistake. CSS deliberately does not: a browser that meets an unparseable declaration throws it away and moves on, and one that meets a malformed rule skips to what it believes is the end of that rule. That forgiveness is why the web is backwards-compatible, and it is also why a stray brace two hundred lines up can make the bottom half of a stylesheet vanish with no error anywhere. The symptom — styles that are simply absent — points at the wrong place, which is what makes these bugs expensive.

A validator is a good way to diagnose a file you already suspect, but the cheaper fix is to not get there. An editor with CSS language support will underline an unbalanced brace as you type it; Stylelint enforces both syntax and conventions and can run on commit; and a build step that parses your CSS fails loudly rather than shipping something broken. Use this tool for stylesheets arriving from elsewhere — a CMS field, a client, a generated file — and let tooling in your editor handle the CSS you write yourself.

Because CSS is designed to fail silently. The specification tells browsers to discard any declaration or rule they cannot parse and carry on with the rest, which is what allows a stylesheet using a brand-new property to work in an old browser. The practical consequence is that a single missing brace can cause the browser to skip every rule that follows it, with nothing in the console to tell you why. Validating is how you find that class of mistake, because the browser will never report it.

Structural and spelling mistakes: braces that do not balance, comments that are never closed, declarations missing the semicolon that separates them, and property names that look like typos of real properties. Those account for most of the cases where a stylesheet mysteriously stops applying partway down. What it does not do is check that your values are valid for each property or that your CSS is a good idea — for that you want Stylelint in your editor and the W3C CSS validator for full specification conformance.

Errors are things that will make a browser discard CSS: unbalanced braces, an unclosed comment, a declaration the parser cannot terminate. Fix those first, because they can silently disable large parts of a file. Warnings are things that parse but are probably not what you meant, such as a property name that closely resembles a real one. A warning can be a false positive if you are deliberately using something unusual, so read them rather than treating them as a checklist.

No, and it is worth keeping the two apart. Validation checks syntax; it says nothing about whether your selectors are maintainable, your specificity is under control, your colours have sufficient contrast, or your stylesheet ships rules nothing uses. Plenty of unmaintainable CSS is perfectly valid. Treat validation as the floor — the mistakes that break things outright — and use linting, review, and accessibility testing for everything above it.

No. Every one of these tools runs entirely in your browser using JavaScript. Your stylesheet is never uploaded, never logged, and never sent to any server — you can confirm this by opening your browser devtools Network tab while you work, or by disconnecting from the internet after the page loads and watching everything continue to function. That makes it safe to paste proprietary or client CSS.