Minifieur CSS/JS

À propos de cet outil

Ce minifieur réduit la taille de votre code CSS ou JavaScript en supprimant les commentaires, les espaces et les retours à la ligne inutiles, pour accélérer le chargement de vos pages sans changer le comportement du code. Il s'appuie sur un véritable découpage lexical : les chaînes, les modèles, les expressions régulières et les sélecteurs sont préservés, les sauts de ligne dont dépend l'insertion automatique des points-virgules sont conservés, et le JavaScript obtenu est vérifié par compilation. Il affiche le gain brut et le gain après compression gzip, qui est celui que perçoit réellement le visiteur.

Comment utiliser cet outil

1. Choisissez le langage (CSS ou JavaScript), puis collez votre code ou importez un fichier .css ou .js.
2. Le code minifié apparaît instantanément, avec la taille avant et après, brute et compressée en gzip.
3. Décochez la conservation des commentaires de licence (/*! … */) si vous n'en avez pas besoin.
4. Copiez le résultat ou exportez-le en fichier .min.css ou .min.js, puis testez-le avant de le publier.

Ce qu'est la minification, et ce que fait cet outil

La minification réduit la taille d'un fichier CSS ou JavaScript sans en changer le comportement. Elle supprime ce qui n'est utile qu'aux humains : commentaires, indentation, espaces superflus et retours à la ligne. Le navigateur lit exactement le même code, mais télécharge moins d'octets.

Les trois dernières lignes demandent de comprendre le code et pas seulement de le « nettoyer » : elles sont le domaine des outils de build (Terser, esbuild, cssnano, Lightning CSS). Cet outil adopte une approche prudente : il fait les trois premières, qui sont sans risque pour peu qu'on respecte la grammaire du langage, et laisse le reste intact. Le gain est moindre, la fiabilité plus grande.

Pourquoi des fichiers plus petits accélèrent un site

Le navigateur ne peut pas afficher une page tant qu'il n'a pas reçu et analysé son CSS : la documentation de MDN rappelle que le CSS bloque le rendu, parce qu'une règle peut en écraser une autre et qu'il faut donc connaître toutes les règles avant de dessiner quoi que ce soit. Le JavaScript, lui, peut interrompre l'analyse du HTML tant qu'il n'est pas chargé et exécuté, sauf s'il est chargé avec les attributs defer ou async. Moins il y a d'octets à transférer sur ces fichiers, plus tôt la page s'affiche, surtout sur une connexion mobile lente.

L'outil d'audit Lighthouse de Google signale d'ailleurs les fichiers CSS et JavaScript non minifiés et chiffre les kilo-octets qu'on pourrait économiser. Son calcul ne compte que les commentaires et les espaces : c'est une estimation prudente, un vrai minifieur économisant généralement davantage. Pour les sites professionnels, la recommandation est d'automatiser la minification dans l'étape de build, avant le déploiement ; pour un petit site qui change rarement, un outil en ligne ponctuel suffit.

Minification et compression gzip : deux économies qui se cumulent

Ne confondez pas les deux étapes. La minification transforme le fichier source en un autre fichier, plus court, qu'on déploie à la place de l'original. La compression (gzip, ou Brotli, plus récent et généralement plus efficace) est appliquée par le serveur au moment de l'envoi, puis annulée automatiquement par le navigateur : le fichier reste identique, mais voyage plus léger. Presque tous les serveurs compressent aujourd'hui les ressources textuelles.

Les deux économies se cumulent, mais pas à parts égales. La compression est très efficace sur les répétitions, dont l'indentation et les espaces. Une fois le fichier compressé, la différence entre la version indentée et la version minifiée est donc plus faible que la différence brute. L'outil affiche pour cette raison les deux mesures : la taille brute avant et après, et la taille après compression gzip estimée par votre navigateur. C'est la seconde qui correspond à ce que télécharge réellement le visiteur.

Pourquoi une minification « naïve » casse du code

Supprimer tous les espaces ou tous les retours à la ligne ne suffit pas : certains blancs ont un sens. Les erreurs ci-dessous sont celles que l'outil évite en analysant le code au lieu de le traiter comme du texte brut.

• En CSS, l'espace est un opérateur. .menu :hover (avec une espace) désigne les éléments survolés à l'intérieur de .menu, alors que .menu:hover désigne le menu lui-même quand on le survole. Les supprimer revient à changer de règle : c'est le « combinateur descendant ». De même, dans calc(100% - 2rem), les espaces autour du « - » sont obligatoires.
• Le contenu des chaînes ne doit jamais être touché. Dans content: " x " ou '// pas un commentaire', les espaces et les barres obliques font partie des données. Une expression régulière comme /a b/ perd son sens si l'on retire l'espace.
• Deux jetons ne doivent pas fusionner. a + +b ne peut pas devenir a++b (qui signifierait « a++ puis b »), ni typeof x devenir typeofx.
• Les sauts de ligne de JavaScript peuvent compter. Le langage insère parfois automatiquement un point-virgule à la fin d'une ligne. return suivi d'un retour à la ligne puis de 1 renvoie undefined, alors que return 1 renvoie 1. Un code écrit sans point-virgule dépend entièrement de ces sauts de ligne. L'outil les conserve aux endroits où l'insertion automatique les rendrait indispensables.
• Une barre oblique peut être une division ou une expression régulière selon ce qui précède : a / b / c est une division, x = /a b/.test(s) contient une regex. Les distinguer demande de suivre le contexte, ce que fait l'outil.

L'outil a été vérifié sur plus de 1 300 fichiers JavaScript réels, y compris du code sans aucun point-virgule : pour chacun, l'arbre syntaxique du code minifié est strictement identique à celui du code d'origine. Pour le CSS, nous avons comparé les styles calculés par le navigateur sur plus de 1 200 éléments de pages du site, en thème clair et en thème sombre : aucune différence avec et sans minification.

Bonnes pratiques de déploiement

1. Gardez toujours le fichier source. Minifié, un fichier est presque illisible : conservez l'original dans votre dépôt et ne modifiez jamais le fichier minifié à la main. Les outils de build produisent aussi des « source maps », des fichiers qui relient le code minifié au code d'origine pour le débogage.
2. Nommez clairement. La convention est style.min.css et script.min.js, à côté de style.css et script.js.
3. Versionnez vos fichiers. Pour profiter d'un cache long sans servir d'ancienne version, ajoutez un identifiant au nom ou à l'adresse du fichier (style.min.css?v=2026-10-08) ou utilisez un nom basé sur son contenu.
4. Testez après minification. Ouvrez la page, parcourez les fonctionnalités principales et regardez la console du navigateur. L'outil vérifie que le JavaScript produit se compile, pas qu'il fait ce que vous attendez.
5. Respectez les licences. Pour du code tiers que vous redistribuez, comme une bibliothèque sous licence MIT, la licence exige que la mention de copyright et le texte de la licence accompagnent le code. Laissez cochée la conservation des commentaires de licence (/*! … */), qui évite de les supprimer.
6. Ne minifiez pas deux fois un fichier déjà minifié : le gain est nul et le risque d'erreur augmente.

Pour valider un fichier JSON avant de l'intégrer à votre projet, utilisez le formateur JSON.

Questions fréquentes