🎨 CSS Formatierer

CSS formatieren oder minifizieren: zwei verschiedene Ziele

"CSS aufräumen" kann zwei ziemlich unterschiedliche Dinge bedeuten, und dieses Werkzeug deckt beide ab. Formatieren bringt unübersichtlichen, zusammengestauchten oder inkonsistent eingerückten CSS-Code in eine lesbare Form: Jede Regel bekommt ihre eigene Zeile, jede Deklaration wird sauber eingerückt, und Selektoren, die durch Kommas getrennt sind, stehen jeweils untereinander. Minifizieren macht genau das Gegenteil: Es entfernt jedes Zeichen, das der Browser zum Verarbeiten der Datei nicht braucht, also Kommentare, Zeilenumbrüche und überflüssige Leerzeichen, damit die ausgelieferte Datei so klein wie möglich wird.

Beide Ziele schließen sich nicht aus, sie gehören zu unterschiedlichen Phasen desselben Projekts. Während der Entwicklung lesen Menschen den Code: Kolleginnen im Review, Sie selbst in drei Monaten, ein neuer Teamkollege, der sich erst noch zurechtfinden muss. Für diese Phase zählt Lesbarkeit mehr als Dateigröße, deshalb formatieren Sie. Sobald die Datei aber auf einem Produktivserver landet und von tausenden Browsern heruntergeladen wird, liest dort niemand mehr den Quelltext, dort zählt nur noch, wie schnell die Datei über das Netzwerk ankommt und wie schnell der Browser sie parsen kann. Für diese Phase minifizieren Sie.

Dieses Werkzeug nutzt für die Formatierung die Prettier-Engine, denselben Formatierer, den ein großer Teil der JavaScript- und CSS-Community bereits in der eigenen Entwicklungsumgebung einsetzt. Das bedeutet, die Ausgabe hier folgt denselben Regeln, die Sie vermutlich schon aus einem Editor-Plugin oder einem Pre-Commit-Hook kennen, es gibt also keine Überraschungen, wenn Sie den formatierten Code anschließend in Ihr Projekt zurückkopieren.

In der Praxis landet dieses Werkzeug auf ganz unterschiedlichen Schreibtischen. Ein Entwickler öffnet die Konsole seines Browsers, kopiert das minifizierte Stylesheet einer fremden Website und formatiert es hier, um zu verstehen, wie eine bestimmte Komponente aufgebaut ist. Eine Frontend-Entwicklerin bekommt einen CSS-Schnipsel per Chat zugeschickt, ohne Zeilenumbrüche und mit uneinheitlicher Einrückung, und bringt ihn vor dem Einfügen ins eigene Projekt erst in eine lesbare Form. Ein technischer Redakteur will ein CSS-Beispiel in einem Blogartikel oder einer Dokumentation zeigen und braucht dafür eine sauber eingerückte Version statt einer einzigen langen Zeile. Und ein Build-Prozess, der gerade kein eigenes Minifizierungs-Tooling eingerichtet hat, nutzt die Minify-Funktion hier für einen schnellen manuellen Zwischenschritt vor dem Deployment.

So verwenden Sie den Formatierer und den Minifizierer

1. CSS einfügen. Fügen Sie Ihren Code in das Editorfeld ein, egal ob er aus einer bestehenden Stylesheet-Datei, einem Design-System oder einer heruntergeladenen, bereits minifizierten Datei stammt.
2. Einrückung wählen. Entscheiden Sie sich für 2 Leerzeichen, 4 Leerzeichen oder Tabs, je nachdem, welche Konvention Ihr Projekt verwendet.
3. Formatieren oder minifizieren. Klicken Sie auf "CSS formatieren" für lesbaren, eingerückten Code oder auf "CSS minifizieren" für eine komprimierte Version ohne überflüssige Zeichen.
4. Ergebnis übernehmen. Kopieren Sie den Code direkt aus dem Ausgabefeld oder laden Sie ihn als eigenständige .css-Datei herunter.

Einrückung wählen: 2 Leerzeichen, 4 Leerzeichen oder Tabs

Bei der Einrückung selbst gibt es technisch keine falsche Wahl, ein Browser interpretiert CSS unabhängig davon, ob eine Deklaration mit zwei Leerzeichen, vier Leerzeichen oder einem Tab eingerückt ist. Trotzdem hat sich im Web eine klare Konvention durchgesetzt.

Prettier, der Formatierer hinter diesem Werkzeug, verwendet standardmäßig 2 Leerzeichen, und genau daran orientieren sich mittlerweile auch die meisten CSS-Dateien im Web. Wer neu in einem Projekt anfängt und keine bestehende Konvention vorfindet, fährt mit dieser Standardeinstellung selten falsch.

Wichtiger als die konkrete Zahl ist am Ende die Konsequenz. Ein Projekt, in dem eine Datei mit zwei Leerzeichen eingerückt ist und die nächste mit vier, erzeugt bei jedem Wechsel zwischen Dateien einen kleinen Stolperstein und macht automatisierte Diff-Vergleiche unnötig unruhig. Viele Teams legen die Konvention deshalb einmal fest und hinterlegen sie in einer .editorconfig-Datei im Projektstamm, die von den meisten Editoren automatisch gelesen wird und die Einrückung beim Speichern durchsetzt, unabhängig davon, welche persönliche Voreinstellung eine einzelne Entwicklerin in ihrem Editor gewählt hat. Ergänzend dazu prüft ein Linter wie Stylelint oder ein Pre-Commit-Hook mit Prettier, dass niemand versehentlich mit der falschen Einrückung committet. Das Ergebnis ist eine Codebasis, die sich liest, als hätte eine einzige Person sie geschrieben, selbst wenn zwanzig Personen daran mitgearbeitet haben.

Warum Formatierung bei Code-Reviews und Git-Diffs zählt

Ein unformatiertes oder inkonsistent eingerücktes Stylesheet verursacht ein Problem, das auf den ersten Blick nichts mit CSS selbst zu tun hat: unleserliche Diffs. Ändert jemand eine einzelne Farbe in einer Regel, die vorher mit Tabs eingerückt war, und speichert der Editor die Datei anschließend mit Leerzeichen, zeigt Git plötzlich nicht eine geänderte Zeile, sondern die gesamte Datei als verändert an. Reviewer sehen dann einen Wall aus rot und grün markierten Zeilen, obwohl sich inhaltlich nur eine einzige Eigenschaft geändert hat.

Das macht Reviews langsamer und fehleranfälliger, weil die eigentliche Änderung in der Menge an Rauschen untergeht. Es erschwert außerdem git blame, das Werkzeug, mit dem Teams normalerweise herausfinden, wer eine bestimmte Zeile zuletzt geändert hat und warum. Wurde eine Zeile nur wegen einer Neuformatierung angefasst, zeigt git blame diese Neuformatierung als letzte Änderung an, statt auf den eigentlichen inhaltlichen Commit zu verweisen, der den Wert tatsächlich festgelegt hat.

Ein Formatierer behebt dieses Problem an der Wurzel, indem er Whitespace, Einrückung und Zeilenumbrüche im gesamten Projekt vereinheitlicht. Läuft er als Pre-Commit-Hook oder in der Build-Pipeline, sieht jede Datei im Repository von Anfang an gleich aus, unabhängig davon, mit welchem Editor und welcher persönlichen Einstellung sie geschrieben wurde. Ein Diff zeigt danach ausschließlich das, was sich inhaltlich geändert hat, eine neue Eigenschaft, ein anderer Wert, eine entfernte Regel, nicht die Nebenwirkungen einer anderen Tastatureinstellung.

Verschachtelte Regeln und Media Queries richtig formatieren

Media Queries und mehrere kommagetrennte Selektoren sind die Stellen, an denen unformatiertes CSS am schnellsten unleserlich wird, weil hier gleich mehrere Ebenen ineinandergeschachtelt werden: eine Bedingung außen, mehrere Selektoren innen und darin wieder mehrere Deklarationen. Ein Beispiel macht den Unterschied deutlich.

So könnte derselbe Codeausschnitt unformatiert in einer heruntergeladenen oder kopierten Datei aussehen:

.card,.card--featured,.card--highlighted{background:#fff;border-radius:4px;-webkit-box-shadow:0 1px 2px rgba(0,0,0,.1);box-shadow:0 1px 2px rgba(0,0,0,.1)}@media (max-width:768px){.card{padding:12px}}

Nach dem Formatieren erhalten Sie stattdessen genau das, was Sie in einer Dokumentation oder einem Codebeispiel erwarten würden:

.card,
.card--featured,
.card--highlighted {
  background: #fff;
  border-radius: 4px;
  -webkit-box-shadow: 0 1px 2px rgba(0, 0, 0, 0.1);
  box-shadow: 0 1px 2px rgba(0, 0, 0, 0.1);
}

@media (max-width: 768px) {
  .card {
    padding: 12px;
  }
}

Drei Dinge fallen an diesem formatierten Ergebnis auf. Erstens steht jeder kommagetrennte Selektor in einer eigenen Zeile, statt sich mit den anderen eine Zeile zu teilen, wodurch auf einen Blick erkennbar ist, wie viele Klassen von derselben Regel betroffen sind. Zweitens rückt der Formatierer den Inhalt einer Media Query eine Ebene weiter ein als den Rest der Datei, sodass die Verschachtelungstiefe sofort sichtbar wird, ohne die geschweiften Klammern einzeln zählen zu müssen. Drittens bleiben vendor-prefixed Eigenschaften wie -webkit-box-shadow exakt an derselben Einrückungsposition wie ihr Standard-Pendant box-shadow, was das paarweise Prüfen erleichtert, ob ein Präfix vergessen wurde.

Was CSS-Minifizierung wirklich entfernt

Eine Minifizierung ändert nichts an der Bedeutung Ihres CSS, sie entfernt ausschließlich das, was der Browser beim Parsen ohnehin ignoriert: Kommentare, Zeilenumbrüche, Einrückung und jedes Leerzeichen, das nicht zur Trennung zweier Werte notwendig ist. Aus mehreren eingerückten Zeilen wie .card { padding: 12px; } wird eine einzige kompakte Zeile wie .card{padding:12px}, funktional identisch, aber ohne die für Menschen gedachte Formatierung.

Der Effekt ist bei kleinen Dateien kaum spürbar, macht sich aber bei größeren Stylesheets deutlich bemerkbar. Ein Design-System oder ein Framework-Stylesheet mit mehreren tausend Zeilen kann durch Minifizierung leicht zwanzig bis vierzig Prozent kleiner werden, allein durch das Entfernen von Whitespace und Kommentaren. Weniger Bytes bedeuten eine kürzere Übertragungszeit über das Netzwerk, besonders auf mobilen Verbindungen, und einen etwas schnelleren Parsing-Vorgang im Browser, weil weniger Zeichen durchlaufen werden müssen. Beides wirkt sich direkt auf Ladezeit-Metriken wie First Contentful Paint aus, die wiederum in Suchmaschinen-Rankings und in der Nutzererfahrung eine Rolle spielen.

Entscheidend dabei: Nichts an diesem Vorgang verändert, wie Ihre Seite aussieht oder sich verhält. Ein Browser ignoriert Leerzeichen zwischen Deklarationen, Zeilenumbrüche zwischen Regeln und Kommentare ohnehin schon beim Parsen der unformatierten Datei, die Minifizierung entfernt also nur Zeichen, die für die Darstellung von Anfang an bedeutungslos waren. Deshalb minifizieren so gut wie alle Build-Pipelines, die CSS für die Produktion ausliefern, automatisch, es gibt kein funktionales Risiko, nur einen Lesbarkeitsverlust, der für eine bereits ausgelieferte Datei ohnehin keine Rolle mehr spielt.

Datenschutz: Ihr CSS bleibt in Ihrem Browser

Formatieren und Minifizieren laufen bei diesem Werkzeug vollständig als JavaScript in Ihrem eigenen Browser-Tab. Es gibt keinen Upload, keine Server-Warteschlange und keinen Zwischenspeicher, der Ihren Code irgendwo außerhalb Ihres eigenen Rechners ablegt. Öffnen Sie während der Nutzung den Netzwerk-Tab der Entwicklerwerkzeuge Ihres Browsers, sehen Sie keine einzige Anfrage, die Ihr CSS an einen Server sendet.

Das unterscheidet dieses Werkzeug von zahlreichen anderen Online-Formatierern, bei denen der eingefügte Code im Hintergrund über eine API an einen Server geschickt, dort verarbeitet und anschließend zurückgeschickt wird, ein Umweg, der für eine öffentliche Beispieldatei unbedeutend ist, für ein noch unveröffentlichtes Design-System, ein Kundenprojekt unter Geheimhaltungsvereinbarung oder proprietäre Markenfarben und Komponentenbibliotheken aber durchaus ein Risiko darstellt. Wer regelmäßig mit Stylesheets arbeitet, die noch nicht öffentlich sind, sei es ein unveröffentlichtes Produkt-Redesign oder ein internes Component-System, profitiert davon, dass dieser Code den eigenen Rechner zu keinem Zeitpunkt verlässt.

Dieselbe clientseitige Architektur sorgt nebenbei auch für Geschwindigkeit: Ohne Server-Anfrage entfällt jede Netzwerklatenz, weshalb selbst ein sehr großes Stylesheet praktisch augenblicklich formatiert oder minifiziert wird, unabhängig davon, wie schnell Ihre Internetverbindung gerade ist.

Häufig gestellte Fragen

Verwandte Entwicklertools

🔒 100% Clientseitige Privatsphäre

Die gesamte CSS-Formatierung und -Minifizierung erfolgt <strong>vollständig in Ihrem Browser</strong>. Es wird kein Code auf einen Server hochgeladen. Ihre proprietären Designs bleiben jederzeit auf Ihrem Gerät.