🛡️ Entités HTML
Encodez en toute sécurité les caractères spéciaux en entités HTML, ou décodez-les pour retrouver du texte brut.
Qu'est-ce qu'une entité HTML ?
Une entité HTML est une façon d'écrire un caractère qui pourrait autrement perturber l'analyse d'une page par le navigateur. Elle prend deux formes possibles : une entité nommée, qui commence par une esperluette et se termine par un point-virgule, comme <, ou une entité numérique, qui utilise le code du caractère dans la table Unicode, en décimal comme < ou en hexadécimal comme <. Les trois écritures produisent exactement le même résultat visuel une fois interprétées par le navigateur : le caractère < affiché tel quel, sans être pris pour le début d'une balise.
Le nom d'une entité est pensé pour rester lisible par une personne qui relit le code source. © évoque immédiatement le symbole du copyright, alors que son équivalent numérique © demande de connaître la table de correspondance par coeur. À l'inverse, la forme numérique a l'avantage d'être universelle : elle fonctionne même pour des caractères qui n'ont jamais reçu de nom officiel, ou dans des contextes où seul un sous-ensemble restreint d'entités nommées est reconnu. En pratique, préférez une entité nommée quand elle existe et que vous écrivez du HTML classique, et gardez la forme numérique en réserve pour les caractères plus rares ou pour des formats qui exigent une syntaxe strictement définie.
Ce mécanisme existe depuis les tout débuts du web parce que le HTML est lui-même un langage textuel : un navigateur ne peut pas deviner si le caractère < que vous avez tapé annonce une vraie balise ou fait simplement partie de votre phrase. Les entités lèvent cette ambiguïté une fois pour toutes en donnant à chaque caractère sensible une écriture qui ne peut jamais être confondue avec du code.
- Collez votre texte ou votre code - qu'il contienne déjà des entités ou des caractères bruts
- Cliquez sur « Encoder HTML » pour transformer les caractères réservés en entités sûres à afficher
- Ou cliquez sur « Décoder HTML » pour retrouver le texte lisible à partir d'entités existantes
- Copiez ou téléchargez le résultat, sans configuration ni compte à créer
Quels caractères faut-il échapper, et pourquoi
Le langage HTML réserve un petit nombre de caractères à un usage syntaxique précis, et c'est justement pour cette raison qu'ils posent problème dès qu'ils apparaissent dans du texte normal. Le signe < annonce le début d'une balise, > en marque la fin, & introduit une entité, et les guillemets " et ' délimitent la valeur d'un attribut. Si vous collez un fragment de code contenant <div> directement dans le corps d'un tutoriel ou d'un article de blog sans l'échapper, le navigateur ne l'affiche pas comme du texte : il tente de l'interpréter comme une vraie balise div, et le fragment que vous vouliez montrer disparaît purement et simplement du rendu final de la page.
Échapper ces caractères consiste à remplacer chacun d'eux par son entité correspondante avant de les insérer dans le HTML. Le tableau suivant reprend les cinq entités prédéfinies héritées du XML, restées les plus utilisées en pratique aujourd'hui :
| Caractère | Entité nommée | Rôle |
|---|---|---|
< | < | Ouvre une balise |
> | > | Ferme une balise |
& | & | Introduit une entité |
| " | " | Délimite un attribut entre guillemets doubles |
| ' | ' | Délimite un attribut entre guillemets simples |
Ces cinq entités sont dites prédéfinies parce que la spécification XML les impose explicitement, quel que soit le document. En HTML, la règle est un peu plus souple : l'apostrophe n'a techniquement pas besoin d'être échappée dans le corps d'un texte, contrairement au XML et au XHTML, qui exigent les cinq sans exception pour qu'un document reste valide. Dans les faits, mieux vaut échapper systématiquement les cinq, ce comportement plus permissif du HTML n'étant qu'une tolérance et non une recommandation à suivre.
Espaces insécables et caractères typographiques
Toutes les entités ne servent pas à protéger la structure d'une page : certaines existent simplement parce que le caractère qu'elles représentent est difficile à taper directement au clavier ou risque d'être altéré par un correcteur automatique. L'espace insécable, , en est l'exemple le plus courant : elle empêche un retour à la ligne malvenu entre deux mots qui doivent visuellement rester ensemble, comme un nombre et son unité.
D'autres entités couvrent des symboles typographiques fréquents dans un texte rédigé : © pour le symbole du copyright, ™ pour la marque déposée, … pour des points de suspension groupés en un seul caractère plutôt que trois points séparés, — pour le tiret long utilisé en anglais dans une incise, et – pour le tiret court utilisé notamment dans un intervalle numérique comme une plage de dates. Écrire ces caractères sous forme d'entités garantit qu'ils s'affichent correctement même si l'encodage du fichier source venait à poser problème quelque part dans la chaîne de publication.
La typographie française a justement son propre usage de l'espace insécable, indépendamment de toute question d'encodage : la règle veut qu'un espace insécable précède un point d'interrogation, un point d'exclamation, deux points ou un guillemet fermant français comme ». Sans cette entité, un navigateur peut couper la ligne juste avant la ponctuation, laissant un point d'interrogation isolé en début de ligne suivante, ce qui casse la lecture. Utiliser devant ces signes de ponctuation n'est donc pas une simple habitude esthétique, c'est une convention typographique française à part entière que ce genre d'outil permet d'appliquer correctement dans du contenu HTML.
Attributs et texte visible : le contexte change la règle
L'endroit où un caractère apparaît dans le document détermine quelles entités sont réellement nécessaires. Dans le texte visible d'une page, entre deux balises, seuls < et & posent un risque réel, puisque ce sont les deux seuls caractères que l'analyseur HTML interprète activement à cet endroit. À l'intérieur d'un attribut délimité par des guillemets doubles, en revanche, c'est le guillemet double lui-même qui devient dangereux, car il referme prématurément l'attribut si vous ne l'échappez pas.
Prenez l'exemple d'un attribut title destiné à afficher une infobulle contenant une citation :
<span title="Il a dit "bonjour" en entrant">survol</span>
Le navigateur lit ce fragment et referme l'attribut title dès le premier guillemet rencontré après Il a dit, laissant bonjour" en entrant" comme du texte brut en dehors de l'attribut, ce qui casse entièrement la balise. La version correcte échappe le guillemet interne avec " :
<span title="Il a dit "bonjour" en entrant">survol</span>
Le même principe s'applique à un attribut alt sur une image, ou à n'importe quel autre attribut entre guillemets : tout guillemet du même type que celui qui délimite l'attribut doit être échappé, sans quoi le navigateur considère que l'attribut se termine à cet endroit précis, bien avant la fin réelle du texte voulu.
Ce détail explique aussi pourquoi la plupart des générateurs de HTML choisissent d'échapper systématiquement le guillemet double, même dans un attribut délimité par des guillemets simples : mieux vaut une entité superflue qu'un attribut mal fermé selon le contexte où le fragment sera réutilisé.
La sécurité : l'échappement comme première défense contre les injections
Échapper le texte fourni par un utilisateur avant de l'afficher sur une page constitue la protection la plus élémentaire contre les attaques par injection de script, plus connues sous le nom d'attaques XSS. Le principe est simple : tout contenu qui provient d'ailleurs que de votre propre code, un commentaire, un nom d'utilisateur, un champ de recherche, doit être traité comme du texte pur et jamais comme du HTML de confiance.
Imaginez un champ de commentaires sur un blog qui affiche directement ce que chaque visiteur a tapé, sans échappement. Un visiteur malveillant pourrait soumettre un commentaire contenant une balise script qui redirige les autres lecteurs vers un site frauduleux et transmet leurs cookies de session au passage. Si ce texte est inséré tel quel dans la page, le navigateur de chaque personne qui consulte ensuite ce commentaire exécute réellement ce script. En échappant systématiquement < et & avant l'affichage, ce même commentaire s'affiche comme du texte inoffensif, visible mais totalement inerte pour le navigateur, incapable de s'exécuter.
C'est précisément pour cette raison que l'encodage HTML reste une étape incontournable dans tout système qui affiche du contenu généré par ses utilisateurs, des commentaires aux avis clients en passant par les messages privés. Décoder des entités effectue l'opération inverse : reconvertir un texte déjà échappé, par exemple récupéré depuis une base de données ou une API, en caractères lisibles pour l'afficher dans un éditeur ou le réutiliser tel quel ailleurs.
Ce mécanisme de protection doit s'appliquer chaque fois que du texte non fiable rejoint une page, que ce soit côté serveur au moment de générer le HTML ou côté client lors d'une mise à jour dynamique du contenu. Un seul point d'affichage oublié suffit à rouvrir la faille, ce qui explique pourquoi la plupart des cadriciels modernes échappent désormais le texte par défaut et exigent une action explicite pour insérer du HTML brut sans filtrage.
Encodage HTML et règles XML : une nuance à connaître
Le HTML et le XML partagent le même vocabulaire d'entités, mais pas tout à fait les mêmes règles. Un document XML ou XHTML doit rester bien formé pour être valide, ce qui impose d'échapper systématiquement les cinq entités prédéfinies, apostrophe comprise, à chaque occurrence. Le HTML classique tolère quelques écarts, comme une apostrophe non échappée dans du texte courant, sans que le navigateur ne rejette la page pour autant. Cette souplesse ne dispense pas de la prudence : dès qu'un même contenu doit circuler entre un flux HTML et un flux XML, comme un flux RSS ou un export de données, échapper les cinq entités par défaut évite les mauvaises surprises d'un format à l'autre.
Confidentialité : encodage et décodage restent dans votre navigateur
Encoder ou décoder du HTML implique souvent de coller des fragments qui n'ont pas encore été publiés : un extrait de documentation interne, un gabarit d'e-mail contenant des données de test, ou le contenu d'un champ avant qu'il ne soit intégré à une application encore en développement. Beaucoup d'outils en ligne équivalents font transiter ce texte par un serveur distant avant de vous renvoyer le résultat, un aller-retour que la plupart des utilisateurs ne remarquent jamais.
Cet outil effectue toute l'opération en JavaScript, exécuté directement dans votre navigateur au moment où vous cliquez sur « Encoder HTML » ou « Décoder HTML ». Aucun texte n'est envoyé à un serveur, aucune requête réseau ne transporte votre contenu, ce qui reste vrai même pour un fragment de code source ou un extrait sensible que vous ne voudriez pas voir transiter ailleurs. Le texte que vous collez disparaît dès que vous fermez l'onglet, sans copie conservée nulle part.
Questions Fréquentes
Outils de Développement Associés
🔒 100 % Privé et Sécurisé
Tout l'encodage et le décodage HTML s'effectuent <strong>entièrement dans votre navigateur</strong>. Aucun texte ni code n'est jamais envoyé sur un serveur. Vos extraits restent sur votre appareil à tout moment.