Free · Fast · Privacy-first

Linter CSS en Ligne

Lintez votre CSS pour les erreurs strictes et les avertissements de bonnes pratiques avec le linter en ligne FixTools, qui vérifie la syntaxe contre les spécifications CSS publiées, valide les valeurs contre les grammaires par propriété, et fait remonter les motifs structurels techniquement légaux mais connus pour causer des problèmes de maintenance à long terme à travers navigateurs et membres d'équipe.

⚡

Vérifie les erreurs de syntaxe et valeurs invalides

🔒

Signale les avertissements de bonnes pratiques avec les erreurs

✨

Identifie les problèmes de préfixes vendeur et propriétés dépréciées

⚡

Gratuit, instantané et basé navigateur

Coût: Gratuit à vie
Inscription: Non requise
Traitement: Dans votre navigateur
Confidentialité: Fichiers locaux

GratuitSans inscriptionMarque blanche

Ajoutez Validator Optimizer à votre site

Intégrez Validator Optimizer dans n'importe quelle page — article de blog, doc produit, intranet, portail scolaire — avec une seule ligne de HTML. Vos visiteurs utilisent l'outil complet, traité entièrement dans leur navigateur. Pas de backend, pas d'upload, pas d'inscription.

Les fichiers restent à 100 % dans le navigateur du visiteur
Responsive — s'adapte à toute largeur de conteneur
Gratuit pour toujours, aucune clé API requise

Code d'intégration

<iframe
  src="https://www.fixtools.io/css-tool/validator-optimizer?embed=1&lang=fr"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Validator Optimizer by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/css-tool/validator-optimizer?embed=1&lang=fr"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Validator Optimizer by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution conviviale : un petit lien « Propulsé par FixTools » apparaît en bas de l'embed.

Linter CSS : aller au-delà des erreurs de syntaxe pour attraper les problèmes avant qu'ils causent une dette de maintenance

Un linter CSS est matériellement plus complet qu'un simple vérificateur de syntaxe, bien que les deux soient souvent confondus dans la conversation décontractée. Un vérificateur de syntaxe répond à une seule question : ce CSS est-il grammaticalement valide ? Un linter répond à cette question puis continue à en poser plusieurs autres. Y a-t-il des motifs ici qui sont techniquement valides aujourd'hui mais historiquement connus pour causer des problèmes ? Y a-t-il des propriétés dupliquées qui ressemblent à des accidents de copier-coller ? Y a-t-il des déclarations avec préfixes vendeur manquant leurs équivalents standards ? Le linter traite votre feuille de style comme un actif à longue durée de vie qui devrait non seulement fonctionner aujourd'hui mais aussi être bon marché à maintenir sur des années.

Les avertissements produits par un linter CSS sont catégoriquement distincts des erreurs et devraient être traités ainsi. Les erreurs décrivent du code que le navigateur rejettera carrément ; les avertissements décrivent du code que le navigateur exécutera volontiers aujourd'hui mais que les développeurs expérimentés ont appris à éviter. Un avertissement pour une déclaration de propriété dupliquée ne signifie pas qu'un style visible est cassé maintenant, cela signifie généralement qu'un éditeur précédent du fichier a ajouté la seconde déclaration sans retirer la première, et le fichier livre maintenant silencieusement une contradiction. Chaque avertissement est une petite opportunité de réduire le risque futur sans urgence.

L'argument professionnel pour linter le CSS reflète l'argument pour linter dans tout autre langage : cela impose une qualité de base automatiquement, réduit la charge cognitive sur les humains durant la revue de code, et empêche les petites erreurs accumulées de se composer en dette de maintenance coûteuse sur la vie du projet. Une feuille de style qui passe systématiquement un linter n'est pas seulement sans erreur, elle est activement maintenue à un standard qui rend le prochain changement plus facile, plus sûr et plus rapide. Les équipes qui lintent régulièrement tendent à intégrer de nouveaux ingénieurs plus rapidement car la base de code encode ses conventions de qualité dans l'outillage plutôt que dans la connaissance tribale.

Il y a aussi un bénéfice moins évident à linter qui mérite d'être nommé. La discipline de prêter attention aux avertissements de lint, plutôt que de les rejeter comme du bruit, change graduellement comment les développeurs pensent au CSS lui-même. Chaque catégorie d'avertissement correspond à un concept réel dans la spécification ou dans l'histoire de l'ingénierie navigateur : cycles de dépréciation, cycles de vie de préfixes vendeur, arithmétique de spécificité, motifs d'interaction de cascade, caractéristiques de performance. Lire et adresser les avertissements enseigne ces concepts dans le contexte du propre code du développeur. Au fil du temps, une habitude de linting soigneux produit des ingénieurs qui écrivent du CSS de meilleure qualité dès le départ.

Référence CSS MDN Spécification CSS

How to use this tool

💡

Collez votre CSS et cliquez sur Valider. Les erreurs (à corriger) et avertissements (à examiner) sont signalés avec explications.

Comment Ça Marche

Guide étape par étape pour linter css en ligne:

1
Collez votre CSS
Ouvrez le Validateur CSS et collez la feuille de style à linter dans le panneau d'entrée. Le linter gère des entrées de toute taille, d'un seul bloc de règle sous revue à un bundle concaténé multi-mégaoctets d'un build de production, sans nécessiter de prétraitement de votre part pour retirer commentaires ou normaliser le formatage.
2
Validez
Cliquez sur Valider pour lancer la passe complète de lint, qui inclut à la fois erreurs de syntaxe et avertissements de bonnes pratiques dans le même rapport. Le linter analyse l'entrée, évalue chaque déclaration et bloc de règle contre la grammaire et les règles de qualité embarquées, et affiche les résultats à côté du panneau d'entrée en une fraction de seconde.
3
Examinez les erreurs d'abord
Traitez les erreurs strictes avant de toucher aux avertissements. Les erreurs signifient que des parties du CSS sont invalides et le navigateur les sautera silencieusement, donc elles ont le plus grand impact immédiat sur le comportement visible. Les corriger d'abord efface aussi tout avertissement faux positif en cascade qui peut avoir été généré en aval d'une erreur structurelle.
4
Examinez et agissez sur les avertissements
Une fois les erreurs réglées, parcourez les avertissements un à la fois et décidez lesquels corriger immédiatement, lesquels documenter comme exceptions connues, et lesquels reporter à une tâche de nettoyage planifiée. Chaque avertissement ne nécessite pas une correction le jour même, mais chacun devrait recevoir une décision délibérée plutôt que d'être silencieusement écarté.

Exemples concrets

Situations courantes où cette approche fait vraiment la différence :

Un développeur senior linte la soumission CSS d'un membre junior et utilise le rapport d'avertissements comme base pour une discussion de revue de code sur les bonnes pratiques de préfixes vendeur.

Le senior passe la pull request du junior par le linter avant de s'asseoir pour écrire les commentaires de revue. Plusieurs avertissements sur des préfixes vendeur non appariés deviennent l'épine dorsale de la conversation de revue, qui se transforme en un bref moment d'enseignement sur comment fonctionnent les cycles de vie de préfixes vendeur et pourquoi associer préfixes et propriétés standards importe. Le junior repart avec des conseils concrets et spécifiques ancrés dans son propre code.

Un développeur linte une bibliothèque CSS qu'il considère adopter et trouve 12 avertissements sur propriétés dépréciées, qu'il intègre dans sa décision d'utiliser la bibliothèque.

Avant de s'engager dans un framework CSS tiers comme dépendance, le développeur colle sa feuille de style compilée dans le linter comme vérification de due diligence. Les douze avertissements sur l'usage de propriétés dépréciées indiquent que la bibliothèque n'a pas été mise à jour pour refléter les changements de spécification actuels, ce qui soulève une préoccupation crédible sur l'activité de maintenance du projet. Le développeur factorise ce signal dans son évaluation.

Une équipe linte sa base de code CSS entière avant de commencer une refactorisation majeure, utilisant le rapport d'avertissements comme liste de départ de dette technique à adresser.

En entrant dans une refactorisation CSS multi-semaines planifiée, l'équipe linte sa feuille de style entière pour produire un inventaire de base d'avertissements, qu'elle catégorise ensuite en seaux à corriger absolument, à corriger de préférence et à accepter avec commentaire. Le rapport d'avertissements devient l'épine dorsale du backlog de refactorisation. À la fin de la refactorisation, ils relintent pour confirmer que le nombre d'avertissements a substantiellement chuté.

Une équipe plateforme linte le CSS produit par un outil de codegen interne pour valider que la sortie du générateur reste dans les motifs acceptés.

L'équipe plateforme maintient un outil interne qui génère du CSS depuis une spécification de tokens de design de plus haut niveau, et ils ajoutent une étape de linting de routine contre la sortie générée dans le cadre de leur CI. Quand un changement de générateur produit accidentellement des feuilles de style avec une nouvelle classe d'avertissement, le rapport de lint fait remonter la régression avant que les consommateurs en aval ressentent l'effet.

When to use this guide

Utilisez cet outil quand vous voulez plus qu'une vérification d'erreurs basique, quand vous voulez identifier non seulement ce qui est cassé mais ce qui pourrait devenir un problème à l'avenir.

Conseils d'experts

Obtenez de meilleurs résultats avec ces suggestions d'experts :

Lintez avant d'ajouter du CSS à une base de code partagée

Quand vous contribuez du CSS à un projet d'équipe, lancez le linter sur vos changements avant d'ouvrir une pull request. Un résultat de lint propre signale aux relecteurs que votre code respecte le standard de qualité de base et permet à la revue de se concentrer sur l'intention de design et l'adéquation architecturale plutôt que sur les problèmes mécaniques. Les relecteurs passent moins de temps à pointer les doublons et dépréciations.

Suivez le nombre d'avertissements dans le temps

Si vous lintez une feuille de style sur une cadence régulière, hebdomadaire, mensuelle, par release, gardez une note du nombre d'avertissements. Un nombre croissant dans une feuille de style croissante est un signe que la qualité se dégrade plus vite qu'elle n'est maintenue, tandis qu'un nombre décroissant signale un investissement actif dans la réduction de dette technique. Les deux tendances sont des informations utiles.

Utilisez le linting avec un formateur CSS

Formatez votre CSS d'abord pour normaliser indentation, sauts de ligne et ordre des déclarations, puis lintez la sortie formatée. Le CSS formaté produit des rapports de lint significativement plus faciles à exploiter car les numéros de ligne signalés et le contexte environnant correspondent à comment le lecteur humain perçoit le fichier. Le pipeline en deux étapes, formater puis linter, devient une habitude de qualité fluide.

Lintez le CSS des outils de design systems

Le CSS exporté depuis des outils de design comme Storybook, Figma ou Webflow contient souvent des valeurs de propriétés dépréciées et des extensions vendeur qui reflètent des décisions de support navigateur plus anciennes cuites dans l'exporteur. Linter la sortie avant import dans votre base de code vous permet d'attraper et nettoyer ces motifs hérités à la frontière, plutôt que les laisser se propager dans une base de code où les futurs mainteneurs supposeront que les motifs étaient des choix intentionnels.

Examinez les avertissements même s'ils ne sont pas des erreurs

Les avertissements CSS indiquent des motifs techniquement valides mais connus pour causer des problèmes futurs. Examiner et adresser les avertissements empêche les petits problèmes qu'ils représentent de s'accumuler en dette technique significative.

Prêtez attention aux avertissements de préfixes vendeur

Les avertissements sur les préfixes vendeur sans équivalents standards identifient les propriétés où vous pourriez compter sur une extension spécifique au navigateur. Ajouter l'équivalent standard garantit que votre CSS fonctionne quand le support navigateur change.

Utilisez les résultats de linting pour améliorer votre connaissance CSS

Chaque type d'avertissement ou erreur d'un linter CSS correspond à un concept ou bonne pratique CSS. Chercher la spécification pour un avertissement signalé est l'un des moyens les plus rapides d'approfondir la connaissance CSS.

FAQ

Questions fréquentes

Un vérificateur de syntaxe répond à une question étroite : ce CSS est-il grammaticalement valide contre la spécification ? Un linter répond à cette question puis continue à poser une série de questions supplémentaires sur les bonnes pratiques, la maintenabilité et le risque futur. Le linter vérifie les propriétés dupliquées, les équivalents de préfixes vendeur manquants, l'usage de valeurs dépréciées, la spécificité suspectement élevée et motifs similaires qui sont du CSS légal mais historiquement problématiques.

Non. Avertissements et erreurs sont catégoriquement différents. Les avertissements décrivent du CSS valide que le linter signale comme potentiellement problématique basé sur la connaissance accumulée des bonnes pratiques, tandis que les erreurs décrivent du CSS invalide que le navigateur rejettera simplement. Les deux méritent attention, mais la réponse à chacun est différente : les erreurs doivent être corrigées car elles cassent activement des règles, tandis que les avertissements sont consultatifs et devraient recevoir une décision de triage délibérée.

Le linter CSS se concentre sur la conformité aux spécifications, la correction syntaxique et les bonnes pratiques spécifiques au CSS. Il n'effectue pas de vérifications spécifiques à l'accessibilité comme les ratios de contraste de couleur contre les seuils WCAG, la couverture des styles de focus sur les éléments interactifs, ou le comportement de réduction de mouvement pour les utilisateurs avec sensibilités vestibulaires. Pour ces vérifications, associez le linter avec un outil de test d'accessibilité dédié qui peut évaluer la page rendue.

Le linter en ligne applique un ensemble standard et opinié de vérifications conçu pour convenir à la majorité des feuilles de style réelles sans configuration. Pour les projets qui ont besoin de règles configurables, de niveaux de sévérité personnalisés, de guides de style spécifiques au projet ou de désactivation sélective de règles, un linter en ligne de commande comme stylelint avec un fichier de configuration versionné est le meilleur choix car il peut être ajusté aux conventions exactes d'une base de code donnée.

Non. Les propriétés personnalisées CSS de la forme --variable-name: value sont une fonctionnalité CSS standard et bien établie, pas un motif déprécié ou risqué. Le linter les reconnaît et ne signale pas leur utilisation comme avertissement. Les valeurs de propriétés personnalisées sont intentionnellement non typées, ce qui signifie que le linter n'impose pas une forme de valeur spécifique pour elles non plus ; ce qu'il impose est la validité structurelle de la déclaration elle-même.

Oui, mais seulement sur la sortie CSS plaine compilée du préprocesseur, pas sur les fichiers source SCSS, Sass, Less ou Stylus directement. Les fichiers source de préprocesseur contiennent une syntaxe qui n'est pas du CSS valide, dont imbrication, variables, mixins et directives de contrôle, et alimenter cette source dans le linter générera un flot d'erreurs non pertinentes. Lancez votre build préprocesseur d'abord, puis collez le CSS plain résultant dans le linter.

Un avertissement de propriété dupliquée signifie que le même nom de propriété apparaît plus d'une fois à l'intérieur du même bloc de règle. C'est généralement un artefact de copier-coller plutôt qu'un choix intentionnel. Le navigateur résout les doublons en utilisant la dernière valeur déclarée, donc les déclarations antérieures sont effectivement du code mort. L'avertissement existe car le code mort dans le CSS est déroutant pour les futurs mainteneurs.

Pour les projets en développement actif, lintez avant chaque commit ou chaque pull request pour qu'aucun changement n'atteigne la branche partagée sans passer la porte de qualité de base. Pour les sites statiques ou packages de design system avec changements peu fréquents, lintez avant chaque release pour confirmer que l'artefact que vous livrez ne s'est pas dégradé silencieusement. Un linting plus fréquent est presque toujours meilleur qu'un linting moins fréquent.

Non. Les avertissements méritent attention mais pas panique. Chaque avertissement devrait recevoir une décision délibérée plutôt qu'une correction automatique, car certains représentent des choix intentionnels dans votre base de code, comme un préfixe vendeur que vous gardez pour le support de navigateurs hérités, qui devraient être documentés plutôt que retirés. La bonne discipline est de parcourir chaque avertissement une fois, décider individuellement de corriger, documenter ou reporter.