Minifier du HTML en Un Clic
Réduisez les espaces et supprimez les commentaires de votre HTML pour diminuer sa taille instantanément.
Votre balisage reste sur votre appareil
Rien à supprimer ensuite
Sûr pour des textes non publiés
Fonctionne dans tout navigateur moderne
Comment ça marche
- 1
Collez votre HTML
Un document complet, un gabarit d’e-mail ou un fragment qu’un serveur insère dans une page.
- 2
Lisez le rapport
Comparez la taille minifiée à la taille compressée et parcourez les avertissements avant de remplacer l’original.
- 3
Copiez la sortie
Emportez-la dans une sortie de build, un fichier de gabarit ou un document intégré.
Pourquoi cet outil
Espace signifiant conservé
L’espace entre éléments en ligne est un espace-mot réellement affiché : il est conservé au lieu d’être réduit à néant.
pre et textarea intacts
Tous deux préservent les espaces par spécification, et reformater leur contenu change ce que le visiteur lit.
Balises fermantes laissées en place
Les retirer mise sur la récupération d’erreur de l’analyseur, un pari que cet outil ne prend pas.
script et style traités correctement
Les blocs embarqués sont d’autres langages, et une chaîne contenant une séquence de fermeture de script n’est pas lue comme du balisage.
Honnête sur le gain
Le document est généralement le plus petit de vos trois fichiers, et les chiffres affichés le disent.
Rien ne quitte le navigateur
Le balisage est traité sur cette page : brouillons et adresses de préproduction ne sont pas confiés à un serveur.
En HTML l’espace est parfois signifiant, et c’est là toute la difficulté
En CSS et en JavaScript, l’espace hors chaîne ne porte aucun sens et peut être supprimé en bloc. HTML ne fonctionne pas ainsi. Une suite d’espaces entre deux éléments en ligne se réduit à un espace unique et non à rien, et cet espace survivant est un espace-mot affiché : retirez le saut de ligne entre `<span>Total</span>` et `<span>Prix</span>` et les deux mots se collent à l’écran. Il en va de même entre un lien et le texte qui le suit, entre des éléments `<a>` voisins dans une navigation, et autour de `<img>` et `<button>`. C’est pourquoi une page minifiée peut soudain se lire « DéconnexionRéglages », et pourquoi la règle sûre est de ne réduire les espaces qu’entre éléments de bloc, là où le navigateur n’affichait de toute façon aucun écart. Savoir dans quel cas vous êtes suppose de connaître la valeur display de chaque élément, laquelle dépend de votre CSS : un outil qui ne voit que le balisage doit donc rester prudent, et celui-ci l’est.
pre et textarea préservent les espaces par spécification
Deux éléments rendent l’espace porteur au sens le plus fort. Dans `<pre>`, chaque espace et chaque saut de ligne s’affiche tel qu’écrit, et c’est pour cela que les exemples de code et les mises en page ASCII y survivent et nulle part ailleurs ; réindenter un bloc `<pre>` change le code que voit votre lecteur, et le réduire détruit l’exemple entier. `<textarea>` se comporte de même pour sa valeur initiale : l’espace du texte par défaut d’un formulaire est du contenu, pas de la mise en forme — et l’analyseur supprime un saut de ligne placé immédiatement après la balise ouvrante, si bien qu’un outil qui en ajoute ou en retire un change en silence ce que l’utilisateur trouve dans le champ. Le contenu de `<script>` et de `<style>` échappe lui aussi aux règles d’espace au niveau du balisage, pour une autre raison exposée plus bas. Tout minificateur qui traite le document comme un flux uniforme de balises et de texte finira par abîmer l’un de ces cas.
HTML est indulgent, et cela rend la minification agressive plus risquée, non plus sûre
HTML n’a pas d’erreurs d’analyse au sens où CSS et JavaScript en ont. Omettez `</p>`, omettez `</li>`, omettez `</tbody>`, retirez les guillemets d’un attribut : un navigateur se rattrapera et construira quand même un arbre — la spécification définit exactement comment. Les minificateurs en profitent : retirer les balises fermantes optionnelles est une vraie économie d’octets, et la spécification l’autorise. Le piège est que la récupération n’est garantie identique que pour un balisage déjà valide. Dans un document où une balise est déjà déséquilibrée, ou où un `<div>` se trouve dans un `<p>`, retirer les balises optionnelles déplace l’endroit où l’analyseur décide qu’un élément s’est terminé, et l’arbre obtenu est un autre arbre — visible d’ordinaire comme du contenu qui saute hors du bloc auquel il appartenait. C’est aussi un balisage que d’autres lisent : un fragment à fermetures implicites peut casser un moteur de gabarits en aval, un client de messagerie ou un robot utilisant un analyseur XML plus strict. Cet outil laisse les balises fermantes tranquilles, car l’économie est faible et la panne est structurelle.
script et style embarqués sont d’autres langages dans le même fichier
Un bloc `<script>` ou `<style>` n’est pas du balisage, et l’analyseur change de mode en y entrant. Cela a une conséquence précise qui piège les outils naïfs : dans un script classique, l’analyseur cherche les caractères littéraux `</script` et termine l’élément là, même s’ils se trouvent dans une chaîne JavaScript. Un code écrivant `document.write("</script>")` termine donc son propre bloc, et le correctif usuel est de casser la séquence en `"<\/script>"`. Un minificateur qui réécrit les guillemets de chaîne ou ré-échappe le texte sans comprendre cela peut créer la séquence là où elle n’existait pas, et la page se tronque à partir de ce point. Le cas miroir est un minificateur qui traite le contenu du script comme du texte et y réduit les espaces : inoffensif jusqu’à ce qu’il rencontre un littéral de gabarit ou une ligne non terminée où le saut faisait le travail du point-virgule. Traiter correctement ces blocs suppose d’y passer une vraie analyse JavaScript et CSS, pas une analyse de balisage.
Le HTML est le fichier où la minification rapporte le moins
Il faut le dire franchement, car cela change là où placer son effort. Des trois fichiers texte que charge une page, le document est généralement le plus petit, et c’est celui que vous ne pouvez d’ordinaire pas mettre en cache : une feuille de styles et un bundle sont empreintés et conservés un an, tandis que le HTML est récupéré à neuf à presque chaque visite. Cela ressemble à un argument pour le réduire, et ça l’est en partie, mais les chiffres sont modestes : le balisage se compresse extrêmement bien parce qu’il répète les mêmes noms de balises et les mêmes motifs d’attributs des centaines de fois, si bien que gzip ou Brotli côté serveur retire déjà l’essentiel de ce qu’un minificateur retirerait. Les vrais gains dans un document sont structurels : moins de blocs de données intégrés, aucune image base64 géante collée dans la source, aucun état rendu côté serveur déversé dans une balise script. Si votre HTML est réellement volumineux, le minifier n’est pas la solution ; découvrir ce qu’il contient l’est généralement.
Ce que le balisage d’une page laisse filtrer, et pourquoi cela plaide pour un traitement local
Le balisage est le plus discrètement révélateur des trois fichiers. Il porte le texte lui-même, titres et noms de produits compris, y compris pour un lancement qui n’a pas eu lieu, et les commentaires HTML sont l’endroit où les équipes laissent les notes les plus franches : un numéro de ticket, un nom d’hôte de préproduction, un rappel qu’une section reste masquée tant que le juridique n’a pas validé, le nom de l’agence qui a écrit le gabarit. Il porte des champs de formulaire cachés, des identifiants d’analytique, parfois un jeton CSRF et souvent une adresse e-mail publiée nulle part ailleurs. Coller une vraie page dans un minificateur hébergé livre tout cela à un tiers contre la réduction d’octets dont on vient de vous dire qu’elle est la plus faible des trois. Ici tout se passe dans la page que vous lisez : ouvrez les outils de développement avant de coller, et vous verrez le nombre de requêtes rester au même point.
Erreurs courantes à éviter
- Réduire les espaces entre éléments en ligne. Cet espace est un espace-mot affiché : le retirer colle deux mots à l’écran alors que le balisage semble toujours correct.
- Reformater le contenu de `pre` ou de `textarea`. Tous deux préservent les espaces par spécification : réindenter change l’exemple de code ou le texte par défaut du formulaire.
- Retirer les balises fermantes optionnelles pour gagner des octets. La récupération n’est garantie identique que sur un balisage déjà valide ; sur du déséquilibré, l’analyseur termine les éléments ailleurs.
- Laisser une passe au niveau du balisage toucher le contenu d’un `script`. Le littéral `</script` termine l’élément même dans une chaîne JavaScript : ré-échapper peut tronquer la page.
- Attendre de la minification qu’elle règle un document volumineux. Le balisage se compresse très bien, donc le serveur a déjà pris l’essentiel : la cause réelle est souvent un bloc de données intégré.
Comparaison
| Critère | Cet outil | Minificateurs en ligne | Une chaîne de build |
|---|---|---|---|
| Balisage envoyé à un serveur | Jamais | Le plus souvent | Non |
| Conserve les espaces-mots en ligne | Toujours | Variable | Configurable |
| Laisse pre et textarea tranquilles | Oui | Variable | Le plus souvent |
| Retire les balises fermantes optionnelles | Non | Souvent | Configurable |
| Taille compressée affichée | Oui | Rarement | Avec un greffon |
| Prix | Gratuit | Gratuit / offres payantes | Gratuit |
Fonctionnalités
Suppression des commentaires
Les notes de développement et les repères de section partent, les commentaires conditionnels encore utiles restent.
Réduction sûre des espaces
Les suites d’espaces ne sont réduites qu’entre éléments de bloc, là où aucun écart n’était affiché.
Nettoyage des attributs
Les attributs type redondants et les valeurs vides sont retirés là où la spécification HTML en fait la valeur par défaut.
Gestion visible des guillemets
Les guillemets d’attribut ne sont retirés que si la valeur ne peut en avoir besoin, et jamais sur le dernier attribut.
Les deux tailles rapportées
Brute et gzip, car la compression serveur retire déjà l’essentiel de ce que la minification enlève au balisage.
Gros documents pris en charge
Une page rendue de n’importe quelle taille se minifie sans envoi ni plafond.
Rien à installer
Pas d’outil de build, pas d’environnement d’exécution, pas de dépendances : tout se passe sur la page web.
Compatible arabe et RTL
Interface complète en huit langues, dont l’arabe de droite à gauche.
Sécurisé par défaut
Servi en HTTPS, sans suivi du contenu ni envoi à un tiers.
Qui l’utilise
Développeurs front-end
Alléger un gabarit qui ne passe pas par une étape de build.
Développeurs e-mail
Faire passer un gabarit sous la limite de taille d’un client sans casser sa mise en page en tableaux.
Développeurs back-end
Nettoyer un fragment rendu côté serveur avant qu’il ne revienne dans la page.
Qui intègre un document
Compacter un balisage à intégrer là où un plafond de taille strict s’applique.
Questions Fréquentes
Non. Tout s’exécute localement dans votre navigateur — votre texte n’est jamais envoyé, stocké ni partagé.
Oui — entièrement gratuit, sans compte et sans limite.