CSS Unminifier vs Prettier: Wann jedes verwenden

Zuletzt geprueft 2026-05-05. CSS Unminifier und Prettier sind beide Formatter, aber sie loesen verschiedene Probleme. CSS Unminifier liest minifiziertes Produktions-CSS und breitet es wieder aus, sodass jeder Selektor und jede Deklaration in ihrer eigenen Zeile sitzt - ideal zum Debuggen einer ausgelieferten Stylesheet, deren Quelle Sie nicht besitzen. Prettier formatiert CSS-Quellcode, den Sie gerade committen wollen, und wendet die .prettierrc-Regeln Ihres Teams an, damit der Diff jedes Entwicklers sauber bleibt. Waehlen Sie den richtigen in 30 Sekunden mit der untenstehenden Tabelle und lesen Sie den Rest dieses Leitfadens, wenn Sie wissen wollen, warum die falsche Wahl inkonsistente Ausgabe erzeugt. Probieren Sie den CSS Unminifier neben diesem Leitfaden fuer die Lese-ausgelieferte-CSS-Haelfte aus.

Was CSS Unminifier tatsaechlich tut (und was er nicht tun kann)

Der CSS Unminifier auf dieser Website liest einen minifizierten CSS-String (die Art, die von cssnano, csso, clean-css oder einem beliebigen Produktionsbuild erzeugt wird, der CSS durch einen Minifier laufen laesst) und gibt dieselben Regeln mit angemessener Einrueckung, Zeilenumbruechen und einer Deklaration pro Zeile aus. Das Tool laeuft vollstaendig in Ihrem Browser - die Seite ist um das In-Browser-Parsing des Textarea-Inhalts herum aufgebaut, kein Upload, kein Konto. Der woertliche Text auf der Tool-Seite lautet "produktionsgebaute Stylesheet und Sie muessen sie lesen oder bearbeiten"; das ist der kanonische Anwendungsfall.

Was die Unminifizierung wiederherstellt:

• Leerzeichen zwischen Selektoren, Deklarationen und Regelblocks. Die Ausgabe ist wieder Zeile fuer Zeile lesbar.
• Zeilenumbrueche nach jeder Deklaration. Jedes property: value; sitzt in seiner eigenen Zeile.
• Einrueckung innerhalb von Regelblocks. Jede Deklaration ist unter ihrem Selektor eingerueckt.

Was die Unminifizierung NICHT und NICHT KANN wiederherstellen:

• Kommentare. Die meisten Produktions-Minifier strippen Kommentare vor der Ausgabe (cssnano Standard, csso Standard). Einmal entfernt, sind die urspruenglichen Kommentare weg - der Unminifier hat nichts, was er zurueckstellen kann.
• Urspruenglicher Formatierungsstil. Der Unminifier produziert eine kanonische "eine Deklaration pro Zeile"-Ausgabe. Wenn Ihre Quelle eine andere Konvention verwendete (mehrzeilige Selektorlisten eingerueckt, Deklarationen nach visueller Kategorie gruppiert, Vendor-Prefixe ausgerichtet), ist diese Konvention nicht in der minifizierten Datei und kann nicht rekonstruiert werden.
• Variablennamen aus CSS-in-JS oder CSS Modules. Wenn die Build-Pipeline CSS Modules oder ein CSS-in-JS-Tool ausgefuehrt hat, das Klassennamen gehasht hat (.SubmitButton_xY7g3, .modal-_2hqf), sind die urspruenglichen semantischen Klassennamen weg. Der Unminifier zeigt die gehashten Namen, weil das ist, was in der Datei ist.
• Source Maps. Wenn der Produktionsbuild keinen sourceMap-Eintrag bewahrt hat, kann der Unminifier die urspruenglichen Dateipfade oder Zeilennummern nicht wiederherstellen. Er formatiert nur, was im Textarea ist.

Wenn Ihr Ziel "diese minifizierte CSS lesen, damit ich eine bestimmte Regel finden kann" ist, liefert der Unminifier genau das. Wenn Ihr Ziel "die urspruengliche Quelle wiederherstellen" ist, ist das eine andere (und meist unmoegliche) Aufgabe.

Prettier (und Ihr IDE-Auto-Format) macht eine andere Arbeit - hier ist die Linie

Prettier ist ein meinungsfreudiger Quell-Formatter. Sein Input ist CSS-Quellcode, den Sie verfasst haben (oder gerade verfassen wollen), und sein Output ist dasselbe CSS, das gemaess einer Konfigurationsdatei umgeschrieben wurde (typischerweise .prettierrc oder prettier.config.js im Repo-Stamm). Prettier ist dafuer konzipiert, bei jedem Speichern, bei jedem Commit, in einem Pre-Merge-Hook auf CI ausgefuehrt zu werden - der Formatter, der einen einzigen Stil im gesamten Team durchsetzt. Die meisten Editor-Erweiterungen (VS Code "Prettier - Code formatter", JetBrains "Prettier", Sublime "JsPrettier") verkabeln ihn in die Format-beim-Speichern-Aktion.

Zwei Dinge machen Prettier anders als den Unminifier:

1. Prettier ist konfigurationsgesteuert. Trailing-Semikolons, Einrueckungsbreite (2 vs 4), Trailing-Whitespace-Handhabung, Zeilenlaenge, einfaches vs doppeltes Anfuehrungszeichen innerhalb von url() - jedes Team waehlt eine andere Kombination, kodifiziert sie in .prettierrc, und Prettier setzt diese Kombination auf jeder Datei durch. Der Unminifier hat keine Konfiguration; er produziert immer dieselbe kanonische "eine Regel pro Zeile"-Ausgabe.
2. Prettier erwartet lesbare Eingabe. Prettier wurde nicht gebaut, um eine einzeilige minifizierte Stylesheet zu verarbeiten. Er kann auf minifiziertem CSS laufen und wird etwas Formatiertes produzieren, aber die Ausgabe verwendet die eigene Zeilenlaengenregel von Prettier (Standard 80 Zeichen), die eigene Gruppierungskonvention von Prettier und den Anfuehrungszeichenstil von Prettier - die normalerweise NICHT mit der Datei uebereinstimmen, die der Unminifier produzieren wuerde. Schlimmster Fall (selten): Prettier kann sich weigern, CSS zu formatieren, das er als fehlerhaft betrachtet (eine zusaetzliche schliessende Klammer, eine ungueltige Pseudo-Klasse), wo der Unminifier einfach alle Bytes ausgibt, die er empfangen hat.

Das einfachste mentale Modell: CSS Unminifier ist ein Betrachter; Prettier ist ein Schreiber. Der Betrachter ist zum Anschauen einer Datei, die Sie nicht besitzen. Der Schreiber ist zum Committen einer Datei, die Sie besitzen.

Ausgeliefertes CSS schnell lesen: wann CSS Unminifier die schnellste Antwort ist

Drei Workflows sind das kanonische CSS-Unminifier-Territorium. In allen drei ist die Eingabe eine minifizierte Produktions-Stylesheet und das Ziel ist es, sie einmal zu lesen, nicht etwas zu committen:

• Debuggen eines Spezifitaetsbugs in der Produktion. Oeffnen Sie DevTools, schauen Sie sich die Regel an, die gewonnen hat, kopieren Sie ihren vollen Selektor, fuegen Sie die minifizierte CSS in den Unminifier ein, suchen Sie nach dem Selektor. Die unminifizierte Ausgabe macht es einfach, die Kaskade hochzuscannen und zu sehen, welche anderen Regeln im Spiel sein koennten. Schneller als durch eine 200-Zeichen-Zeile zu scrollen.
• Inspizieren einer Drittanbieter-Stylesheet. Wenn eine Vendor-Bibliothek (Bootstrap, kompilierte Tailwind-CSS, CSS eines eingebetteten Widgets) Ihre Styles stoert und Sie die Quelle nicht haben, fuegen Sie die minifizierte Datei in den Unminifier ein und lesen Sie die Regeln direkt. Oft finden Sie die anstoessige Regel in 30 Sekunden.
• Eine saubere Kopie an einen Teamkollegen uebergeben. Ein Bug-Report von QA kommt mit einem minifizierten CSS-Anhang an. Einfuegen, unminifizieren, die formatierte Ausgabe im Bug-Tracker-Kommentar teilen, damit der naechste Leser nicht horizontal scrollen muss.

In allen drei gewinnt der Unminifier, weil er im Browser ist, keine Installation erfordert und Ausgabe produziert, die Sie mit Ctrl-F durchsuchen koennen. Prettier auf derselben Eingabe auszufuehren erfordert entweder eine lokale Installation (npx prettier file.css schreibt auf die Festplatte) oder das Einfuegen in einen Prettier-Playground - beide langsamer als ein Einmal-Einfuegen-Tool, das clientseitig laeuft.

CSS-Quellcode verfassen: wann Prettier die richtige Wahl ist

Drei Workflows gehoeren zu Prettier. In allen drei ist die Eingabe CSS-Quellcode, den der Entwickler verfasst hat, und das Ziel ist es, ihn fuer den Commit zu formatieren:

• Format-beim-Speichern im Editor. VS Code und JetBrains verkabeln Prettier beide in die Format-Aktion, wenn ein .prettierrc im Repo vorhanden ist. Jedes Mal, wenn der Entwickler eine CSS-Datei speichert, schreibt Prettier sie gemaess den Team-Regeln um. Der Unminifier kann nicht in Format-beim-Speichern verkabelt werden (er hat keine CLI; er ist eine Webseite) und wuerde die .prettierrc-Regeln ohnehin ignorieren.
• Pre-Commit-Hook auf Git. Tools wie lint-staged + husky fuehren Prettier auf jeder gestagten CSS-Datei aus, bevor der Commit landet. Der Diff ist immer Prettier-formatiert. Reviewer sehen nur logische Aenderungen, keinen Whitespace-Drift. Der Unminifier hat keine Hook-Integration.
• CI-Format-Check. Ein CI-Schritt fuehrt prettier --check src/**/*.css aus. Wenn eine Datei nicht den Prettier-Regeln entspricht, schlaegt der Build fehl. Erzwingt, dass das lokale Format jedes Entwicklers den Team-Regeln entspricht. Der Unminifier kann keinen Check durchsetzen: seine Ausgabe ist kanonisch-eine-Zeile-pro-Regel, was sich von jedem .prettierrc eines Teams unterscheidet.

Wenn Sie CSS committen, fuehren Sie Prettier aus (via Ihrem Editor, Ihrem Pre-Commit-Hook oder der CLI). Wenn Sie CSS lesen, das Sie nicht besitzen, fuegen Sie es in den CSS Unminifier ein. Das Umgekehrte zu tun - Prettier auf einer minifizierten Stylesheet auszufuehren, um sie "zu lesen" - produziert eine Ausgabe, die NICHT der Quellkonvention Ihres Teams entspricht UND nicht irgendeiner Standard-CSS-Lesekonvention entspricht. Es ist das Schlimmste aus beiden Welten.

Was kein Tool nach einem Tree-Shaking-Build wiederherstellen kann

Produktions-CSS-Pipelines tun mehr als nur minifizieren. Die meisten modernen Build-Ketten fuehren eine Sequenz von Transformationen aus, die Informationen entfernen, und einmal die Information weg ist, kann kein Formatter (der Unminifier oder Prettier) sie zurueckstellen. Zu wissen, was entfernt wurde, hilft, Erwartungen zu setzen, wie Ihre "unminifizierte" Ausgabe aussehen wird:

• Tree-Shaking entfernt ungenutzte Regeln. Tools wie PurgeCSS, UnCSS und Tailwinds JIT-Engine kompilieren die Quelle gegen das HTML/JSX der Anwendung und emittieren nur die Regeln, die zu verwendeten Klassennamen passen. Die Ausgabe-Stylesheet ist eine TEILMENGE der Quelle, in einer anderen Reihenfolge. Der Unminifier kann diese Teilmenge formatieren, aber Ihnen nicht sagen, welche Regeln entfernt wurden.
• Variablennamen-Mangling auf CSS-in-JS oder CSS Modules. CSS Modules schreibt .button in .Button_button_2hQF um (oder kuerzer); CSS-in-JS-Bibliotheken (styled-components, emotion) schreiben .MyButton in .css-1n3v7p9 um. Die gehashten Namen sind deterministisch, aber undurchsichtig. Der Unminifier zeigt die gehashten Namen, weil das ist, was in der Datei ist.
• Kommentare vor dem Build entfernt. Die meisten Minifier entfernen /* ... */-Kommentare standardmaessig. Einige bewahren /*! preserve */-Banner-Kommentare (Lizenz-Header); der Rest ist weg, bevor die Datei die Build-Pipeline verlaesst. Weder der Unminifier noch Prettier stellen sie wieder her.
• Source Maps abgetrennt. Wenn der Build eine style.css.map-Datei emittierte, Sie aber nur style.css haben, koennen Sie nicht zu den urspruenglichen Zeilennummern zurueckkehren. Der Unminifier formatiert, was Sie haben; Prettier tut dasselbe. Beide haengen davon ab, dass Sie auch die Source Map abrufen, wenn Sie eine Navigation zur Originalquelle benoetigen.
• Vendor-Prefix-Kollabierung. Autoprefixer emittiert oft eine einzelne Regel mit mehreren Prefix-Varianten (-webkit-, -moz-, -ms-, Standard). Nach der Minifizierung kann die Prefix-Reihenfolge fuer kuerzeste Ausgabe neu gemischt werden. Der Unminifier zeigt Ihnen diese endgueltige Reihenfolge; die urspruengliche Autoprefixer-Ausgabe hatte eine andere Reihenfolge in der Quelle.

Wenn Ihr Ziel "die Quelle vollstaendig rekonstruieren" ist, lautet die Antwort: oeffnen Sie das Git-Repository des Builds oder holen Sie sich die passende Source Map. Weder CSS Unminifier noch Prettier koennen rekonstruieren, was die Build-Pipeline entfernt hat.

Paaren Sie den Unminifier mit dem Rest des CSS-Toolsets

Wenn die Datei, die Sie lesen, aus Ihrem eigenen Produktionsbuild stammt und Sie sie nach dem Lesen RE-minifizieren werden (der Round-Trip-Pfad "anzeigen, bearbeiten, versenden"), paaren Sie den Unminifier mit dem CSS Minifier auf dieser Website fuer die Rueckreise. Der Minifier kehrt den Format-Schritt um (laesst Leerzeichen und Zeilenumbrueche wieder fallen) und produziert eine bereitstellbare einzeilige Datei. Die beiden Tools zusammen decken beide Richtungen des Produktion-zu-Quelle-zu-Produktion-Loops ab.

Wenn Sie unsicher sind, ob die Datei, die Sie haben, eine "Minifier"-Ausgabe (Leerzeichen entfernt) oder eine "Uglifier"/Tree-Shaker-Ausgabe (Variablen auch umbenannt) ist, erklaert der Leitfaden CSS minifier vs uglifier vs tree-shaking, wie man sie in einem Absatz auseinanderhaelt. Wenn Sie einen Minifier vs einen Kompressor (gzip/brotli) auswaehlen, deckt der Leitfaden minifier vs Kompressor diese benachbarte Verwirrung ab. Wenn Sie eine Cloud Run- oder Lambda-Bereitstellung ausfuehren und sich um Cold-Start-CSS-Bytes sorgen, deckt der Leitfaden wie man CSS/JS fuer Cloud Run Cold-Start minifiziert den budgetgetriebenen Fall ab.

Haeufig gestellte Fragen

Ist die unminifizierte Ausgabe dasselbe wie das urspruengliche CSS?

Fast nie. Der Unminifier kehrt den Leerzeichen-Schritt um, kann aber das Entfernen von Kommentaren, das Mangling von Variablen, das Tree-Shaking oder die Neuordnung von Vendor-Prefixen nicht umkehren. Behandeln Sie die Ausgabe als "lesbares Produktions-CSS", nicht als "urspruengliche Quelle". Wenn Sie die urspruengliche Quelle brauchen, holen Sie sich das Git-Repository des Builds oder die Source Map.

Warum sind meine Variablennamen nach dem Unminifizieren anders?

Sie sind nicht anders - sie sind dieselben Namen, die die Build-Pipeline in die Datei geschrieben hat. Moderne Build-Ketten schreiben Klassennamen durch CSS Modules oder CSS-in-JS-Hashing fuer Scope-Isolation um, sodass die Produktions-Stylesheet .Button_xY7g3 anstelle von .Button enthaelt. Der Unminifier zeigt Ihnen, was in der Datei ist; er kann die Namen nicht ent-hashen, weil die Build-Map nicht vorhanden ist.

Kann ich Prettier auf der unminifizierten Ausgabe ausfuehren?

Ja, und das Ergebnis wird Prettier-formatiert sein (passend zu welchem .prettierrc-Regelsatz Sie Prettier zeigen). Aber der Unminifier produziert bereits eine kanonische "eine Deklaration pro Zeile"-Ausgabe, die gut zum Lesen ist; Prettier darauf auszufuehren aendert nur den Formatstil, um den Team-Regeln zu entsprechen. Die meisten Leser machen sich nicht die Muehe. Wenn Sie kurz davor sind, die Datei als Quelle zu committen, dann ja - fuehren Sie Prettier als naechstes aus, weil Prettier dem Commit-Format Ihres Teams entspricht.

Wird CSS Unminifier mit CSS-Modules-Klassen-Hashes umgehen?

Er wird sie problemlos formatieren (die Hashes sind gueltige CSS-Klassennamen). Was er nicht kann, ist sie zurueck zu den menschenlesbaren Namen aus Ihrer Quelle zu mappen. Wenn Sie die Source Map des Builds haben, kann Ihr DevTools die menschlichen Namen anzeigen, indem es durch die Source Map zurueckmappt; der Unminifier allein kann es nicht.

Gibt es eine Moeglichkeit, Kommentare nach einem Build wiederherzustellen?

Nur wenn der Minifier des Builds konfiguriert war, sie zu bewahren (die meisten sind es standardmaessig nicht). Konfigurieren Sie Ihren Build, um /*! ... */-Banner-Kommentare ueber die preserve- oder comments: 'some'-Option des Minifiers zu behalten. Einmal entfernt, sind Kommentare nicht durch Formatierung wiederherstellbar.

Verwandt

• CSS Unminifier - das Tool, fuer das dieser Leitfaden begleitend geschrieben wurde. Fuegt minifiziertes CSS ein, gibt formatiertes CSS zurueck, laeuft vollstaendig in Ihrem Browser.
• CSS Minifier - das Tool in entgegengesetzter Richtung fuer die Re-Minifizierung nach einem Lesen. Gleiches In-Browser-, Kein-Konto-Setup.
• CSS minifier vs Kompressor - begleitender Leitfaden zur Vorwaertsrichtung. Klaert die Minifier-vs-gzip-Terminologie, die Entwickler oft verwechseln.
• CSS minifier vs uglifier vs tree-shaking - begleitender Leitfaden zur Build-Pipeline-Reihenfolge. Erklaert, was jede Transformation tatsaechlich tut und wann jede anzuwenden ist.
• Wie man CSS/JS fuer Cloud Run Cold-Start minifiziert - bereitstellungsspezifischer Leitfaden fuer Cold-Start-Budgets.