HTML mit Einem Klick Verkleinern
Reduzieren Sie Leerraum und entfernen Sie Kommentare aus Ihrem HTML, um die Größe sofort zu verringern.
Ihr Markup bleibt auf Ihrem Gerät
Nichts, das später zu löschen wäre
Sicher für unveröffentlichte Texte
Läuft in jedem modernen Browser
So funktioniert es
- 1
Fügen Sie Ihr HTML ein
Ein vollständiges Dokument, eine E-Mail-Vorlage oder ein Fragment, das ein Server in eine Seite einsetzt.
- 2
Lesen Sie den Bericht
Vergleichen Sie minifizierte und komprimierte Größe und prüfen Sie die Hinweise, bevor Sie das Original ersetzen.
- 3
Kopieren Sie die Ausgabe
Nehmen Sie sie in eine Build-Ausgabe, eine Vorlagendatei oder ein eingebettetes Dokument mit.
Warum dieses Tool
Bedeutsamer Leerraum bleibt
Der Abstand zwischen Inline-Elementen ist ein dargestellter Wortabstand und wird bewahrt statt weggekürzt.
pre und textarea unberührt
Beide bewahren Leerraum laut Spezifikation, und ihren Inhalt umzuformatieren ändert, was die Besucherin liest.
Schließende Tags bleiben stehen
Optionale Tags zu entfernen setzt auf die Fehlerkorrektur des Parsers — dieses Werkzeug geht die Wette nicht ein.
script und style richtig behandelt
Eingebettete Blöcke sind andere Sprachen, und eine Zeichenkette mit schließender Script-Folge wird nicht als Markup gelesen.
Ehrlich über den Gewinn
Das Dokument ist meist die kleinste Ihrer drei Dateien, und die gezeigten Zahlen sagen das auch.
Nichts verlässt den Browser
Das Markup wird auf dieser Seite verarbeitet, Entwurfstexte und Staging-Adressen gehen also an keinen Server.
Leerraum in HTML ist manchmal bedeutsam, und darin liegt die ganze Schwierigkeit
In CSS und JavaScript trägt Leerraum außerhalb einer Zeichenkette keine Bedeutung und lässt sich pauschal entfernen. HTML funktioniert nicht so. Eine Folge von Leerzeichen zwischen zwei Inline-Elementen fällt auf ein einzelnes Leerzeichen zusammen, nicht auf nichts, und dieses überlebende Leerzeichen ist ein dargestellter Wortabstand: Entfernen Sie den Zeilenumbruch zwischen `<span>Summe</span>` und `<span>Preis</span>`, und die beiden Wörter kleben auf dem Bildschirm aneinander. Dasselbe gilt zwischen einem Link und dem Text danach, zwischen benachbarten `<a>`-Elementen in einer Navigation und rund um `<img>` und `<button>`. Deshalb kann eine minifizierte Seite plötzlich „AbmeldenEinstellungen“ lesen, und deshalb lautet die sichere Regel, Leerraum nur zwischen Blockelementen zusammenzufassen, wo der Browser ohnehin nie einen Abstand dargestellt hat. Welcher Fall vorliegt, hängt vom display-Wert jedes Elements ab, und der hängt an Ihrem CSS — ein Werkzeug, das nur das Markup sieht, muss also zurückhaltend sein, und dieses ist es.
pre und textarea bewahren Leerraum laut Spezifikation
Zwei Elemente machen Leerraum im stärksten Sinn tragend. Innerhalb von `<pre>` wird jedes Leerzeichen und jeder Umbruch so dargestellt, wie er geschrieben wurde, und genau deshalb überleben Codebeispiele und ASCII-Layout dort und sonst nirgends; einen `<pre>`-Block neu einzurücken ändert den Code, den Ihre Leserin sieht, und ihn zusammenzufassen zerstört das Beispiel vollständig. `<textarea>` verhält sich beim Anfangswert genauso, der Leerraum im Standardtext eines Formulars ist also Inhalt und keine Formatierung — und der Parser entfernt genau einen Zeilenumbruch unmittelbar nach dem öffnenden Tag, was bedeutet, dass ein Werkzeug, das einen hinzufügt oder wegnimmt, stillschweigend ändert, was die Nutzerin im Feld vorfindet. Auch die Inhalte von `<script>` und `<style>` liegen außerhalb der Leerraumregeln auf Markup-Ebene, aus einem anderen, weiter unten behandelten Grund. Jeder Minifizierer, der das Dokument als einen einheitlichen Strom aus Tags und Text behandelt, wird irgendwann einen dieser Fälle verstümmeln.
HTML ist nachsichtig, und das macht aggressive Minifizierung riskanter statt sicherer
HTML kennt keine Parse-Fehler in dem Sinn, den CSS und JavaScript kennen. Lassen Sie `</p>` weg, lassen Sie `</li>` weg, lassen Sie `</tbody>` weg, streichen Sie die Anführungszeichen um ein Attribut — ein Browser fängt sich und baut trotzdem einen Baum, und die Spezifikation legt genau fest, wie. Minifizierer nutzen das aus: optionale schließende Tags zu entfernen spart tatsächlich Bytes, und die Spezifikation erlaubt es. Der Haken ist, dass die Wiederherstellung nur für bereits gültiges Markup garantiert identisch ist. In einem Dokument, in dem ein Tag schon unausgeglichen ist oder ein `<div>` in einem `<p>` steckt, verschiebt das Entfernen optionaler Tags die Stelle, an der der Parser ein Element für beendet hält, und der entstehende Baum ist ein anderer Baum — meist sichtbar als Inhalt, der aus dem Kasten springt, in den er gehörte. Es ist außerdem Markup, das andere lesen: ein Fragment mit impliziten Schließungen kann eine nachgelagerte Template-Engine, ein E-Mail-Programm oder einen Crawler mit strengerem XML-Parser brechen. Dieses Werkzeug lässt schließende Tags in Ruhe, weil die Ersparnis klein und der Ausfall strukturell ist.
Eingebettetes script und style sind andere Sprachen in derselben Datei
Ein `<script>`- oder `<style>`-Block ist kein Markup, und der Parser wechselt beim Eintritt den Modus. Das hat eine konkrete Folge, über die naive Werkzeuge stolpern: In einem klassischen Skript sucht der Parser nach den wörtlichen Zeichen `</script` und beendet das Element dort — auch wenn sie in einer JavaScript-Zeichenkette stehen. Code, der `document.write("</script>")` schreibt, beendet damit seinen eigenen Block, und die übliche Abhilfe ist, die Folge als `"<\/script>"` zu brechen. Ein Minifizierer, der Anführungszeichen in Zeichenketten umschreibt oder Text neu maskiert, ohne das zu verstehen, kann die Folge dort erzeugen, wo sie nicht war, und die Seite bricht ab dieser Stelle ab. Der Spiegelfall ist ein Minifizierer, der Skriptinhalte als Text behandelt und den Leerraum darin zusammenfasst: harmlos, bis er auf ein Template-Literal trifft oder auf eine unabgeschlossene Zeile, in der der Umbruch die Arbeit des Semikolons erledigte. Diese Blöcke richtig zu behandeln heißt, einen echten JavaScript- und CSS-Durchgang auf sie anzuwenden, keinen Markup-Durchgang.
HTML ist die Datei, bei der Minifizierung am wenigsten einbringt
Das gehört klar gesagt, weil es ändert, wo sich Aufwand lohnt. Von den drei Textdateien, die eine Seite lädt, ist das Dokument meist die kleinste, und es ist die, die Sie in der Regel nicht zwischenspeichern können — ein Stylesheet und ein Bundle bekommen einen Fingerabdruck und liegen ein Jahr im Cache, während das HTML bei fast jedem Besuch frisch geholt wird. Das klingt nach einem Argument, es zu verkleinern, und teilweise ist es das, doch die Zahlen sind bescheiden: Markup komprimiert außerordentlich gut, weil es dieselben Tag-Namen und Attributmuster hundertfach wiederholt, sodass gzip oder Brotli auf dem Server bereits das meiste wegnimmt, was ein Minifizierer wegnähme. Die echten Gewinne in einem Dokument sind strukturell — weniger eingebettete Datenblöcke, keine riesigen base64-Bilder im Quelltext, kein serverseitig gerenderter Zustand, der in ein script-Tag gekippt wird. Wenn Ihr HTML wirklich groß ist, ist Minifizieren nicht die Lösung; herauszufinden, was darin steckt, ist es meistens.
Was das Markup einer Seite preisgibt, und warum das für lokale Verarbeitung spricht
Markup ist die leiseste und zugleich verräterischste der drei Dateien. Es trägt den Text selbst, samt Überschriften und Produktnamen für einen Start, der noch nicht stattgefunden hat, und HTML-Kommentare sind die Stelle, an der Teams die offensten Notizen hinterlassen — eine Ticketnummer, ein Staging-Hostname, die Erinnerung, dass ein Abschnitt verborgen bleibt, bis die Rechtsabteilung zustimmt, der Name der Agentur, die die Vorlage geschrieben hat. Es trägt versteckte Formularfelder, Analyse-Kennungen, manchmal ein CSRF-Token und oft eine E-Mail-Adresse, die sonst nirgends veröffentlicht ist. Eine echte Seite in einen gehosteten Minifizierer zu kleben, übergibt all das an Dritte — im Tausch gegen die Byte-Ersparnis, von der Sie eben gelesen haben, dass sie die geringste der drei ist. Hier geschieht alles in der Seite, die Sie gerade lesen: Öffnen Sie vor dem Einfügen die Entwicklerwerkzeuge, und Sie werden sehen, dass die Zahl der Anfragen bleibt, wo sie war.
Häufige Fehler, die Sie vermeiden sollten
- Leerraum zwischen Inline-Elementen zusammenfassen. Dieser Abstand ist ein dargestellter Wortabstand, sein Entfernen klebt zwei Wörter aneinander, obwohl das Markup weiterhin richtig aussieht.
- Den Inhalt von `pre` oder `textarea` umformatieren. Beide bewahren Leerraum laut Spezifikation, neues Einrücken ändert also das Codebeispiel oder den Standardtext des Formulars.
- Optionale schließende Tags entfernen, um Bytes zu sparen. Die Wiederherstellung ist nur bei bereits gültigem Markup garantiert identisch; bei Unausgeglichenem endet der Parser Elemente anderswo.
- Einen Durchgang auf Markup-Ebene an `script`-Inhalte lassen. Das wörtliche `</script` beendet das Element sogar in einer JavaScript-Zeichenkette, neues Maskieren kann die Seite abschneiden.
- Von Minifizierung erwarten, dass sie ein großes Dokument löst. Markup komprimiert sehr gut, der Server hat das meiste also schon geholt — die eigentliche Ursache ist meist ein eingebetteter Datenblock.
Im Vergleich
| Aspekt | Dieses Werkzeug | Online-Minifizierer | Eine Build-Pipeline |
|---|---|---|---|
| Markup an einen Server gesendet | Nie | Meistens ja | Nein |
| Behält Inline-Wortabstände | Immer | Unterschiedlich | Konfigurierbar |
| Lässt pre und textarea in Ruhe | Ja | Unterschiedlich | Meistens |
| Entfernt optionale schließende Tags | Nein | Häufig | Konfigurierbar |
| Komprimierte Größe angezeigt | Ja | Selten | Mit einem Plugin |
| Preis | Kostenlos | Kostenlos / kostenpflichtige Stufen | Kostenlos |
Funktionen
Kommentare entfernen
Entwicklungsnotizen und Abschnittsmarken gehen, bedingte Kommentare mit echter Aufgabe bleiben.
Sicheres Zusammenfassen von Leerraum
Folgen von Leerzeichen werden nur zwischen Blockelementen reduziert, wo nie ein Abstand dargestellt wurde.
Attribute aufräumen
Überflüssige type-Attribute und leere Werte entfallen dort, wo die HTML-Spezifikation sie ohnehin voraussetzt.
Nachvollziehbarer Umgang mit Anführungszeichen
Attributanführungszeichen entfallen nur, wenn der Wert sie unmöglich braucht, und nie beim letzten Attribut.
Beide Größen ausgewiesen
Roh und gzip, denn die Serverkompression nimmt bereits das meiste weg, was Minifizierung dem Markup nimmt.
Große Dokumente möglich
Eine gerenderte Seite beliebiger Größe wird ohne Upload und ohne Obergrenze minifiziert.
Nichts zu installieren
Kein Build-Werkzeug, keine Laufzeitumgebung, keine Abhängigkeiten — es läuft in der Webseite.
Bereit für Arabisch und RTL
Die vollständige Oberfläche in acht Sprachen, einschließlich Arabisch von rechts nach links.
Standardmäßig sicher
Über HTTPS ausgeliefert, ohne Inhaltsverfolgung und ohne Upload an Dritte.
Wer es nutzt
Frontend-Entwicklerinnen und -Entwickler
Eine Vorlage verkleinern, die keinen Build-Schritt durchläuft.
E-Mail-Entwicklung
Eine Vorlage unter das Größenlimit eines Programms bringen, ohne ihr Tabellenlayout zu zerlegen.
Backend-Entwicklung
Ein serverseitig gerendertes Fragment aufräumen, bevor es an die Seite zurückgeht.
Wer ein Dokument einbettet
Markup verdichten, das an einer Stelle mit harter Größengrenze eingebettet werden muss.
Häufig Gestellte Fragen
Nein. Alles läuft lokal im Browser — Ihr Text wird nie hochgeladen, gespeichert oder geteilt.
Ja — komplett kostenlos, ohne Konto und ohne Limits.