PDF-Komprimierung im Test: Methode, Dateigröße und Funktionen

Was wurde getestet und was nicht?

Getestet wurde derselbe, unveränderte Kompressionscode, den der PDF-Kompressor dieser Website verwendet. Für die Messung lief er allerdings nicht im Browser, sondern wurde direkt in Node.js aufgerufen. So lassen sich Eingabe, Einstellungen und gespeichertes Ergebnis für jeden Lauf genau festhalten.

• Kompressionsmodul: QPDF 12.2.0 als WebAssembly, Wrapper-Version 0.3.0. Das Build-Skript des Wrappers legt QPDF 12.2.0 fest, und das installierte Modul meldet bei der Abfrage ebenfalls 12.2.0.
• Umgebung: Node.js 24.18.1 unter Windows 11, Build 26200, x64.
• Umfang: drei synthetische Eingabedateien, neun Kompressionsläufe und eine Testdatei mit Signatur-Platzhalter, die abgewiesen werden soll.
• Nachprüfung: zwölf gespeicherte PDFs mit zusammen 24 Seiten, jeweils mit Strukturprüfung und gerenderter Seitenansicht.

Nicht Teil dieser Messung sind:

• die Verarbeitungszeit; es wurde keine Zeit gemessen,
• das Verhalten in einzelnen Browsern oder auf echten Smartphones und Tablets,
• echte Fotos, Scans, große Dateien oder Dokumente von Nutzerinnen und Nutzern,
• andere Kompressionsprogramme oder Onlinedienste,
• eine durchschnittliche Ersparnis, die du für deine Datei erwarten könntest.

Testdateien, Einstellungen und Downloads

Im Test stecken ausschließlich selbst erzeugte PDFs. Es sind keine Kundendokumente, keine Fotos aus der Außenwelt und keine Signaturen echter Personen dabei. Das Bild in der Bilddatei ist ebenfalls generiert: Es zeigt eine Textur mit Farbverlauf und ist weder ein Foto noch ein Scan.

• Textdatei, 3.029 Byte: zwei Seiten mit Text, einem ausgefüllten Formularfeld, einem Link, einer Seitendrehung und einer Markierung im Strukturbaum.
• Bilddatei, 1.359.079 Byte: dieselben Bestandteile, zusätzlich ein generiertes Bild mit 640 × 800 Pixeln. Die Textdatei ohne Bild hat nur 3.029 Byte, der Großteil dieser Dateigröße geht also auf das Bild zurück.
• Bereits optimierte Textdatei, 2.721 Byte: Sie dient als Fall, bei dem sich nichts mehr gewinnen lässt.
• Datei mit Signatur-Platzhalter, 3.139 Byte: Sie enthält nur die Struktur einer Signatur, aber keine echte digitale Signatur. Mit ihr wird geprüft, ob der Kompressor signierte Dateien abweist.

Gleiche Ausgangslage für jeden Lauf

• Jeder Lauf beginnt mit den unveränderten Originalbytes. Braucht ein Lauf mehrere Versuche, startet auch jeder weitere Versuch wieder beim Original und nicht beim vorherigen Ergebnis.
• Alle Ergebnisse enthalten beide vollständigen Seiten. Es wurden keine Seiten entfernt, nichts als ZIP verpackt, keine Bilder auf weniger Pixel heruntergerechnet und keine ganzen Seiten in Bilder umgewandelt. Nur so sind die Bytezahlen der Modi miteinander vergleichbar.
• Jedes Ergebnis wurde unter einem eigenen Dateinamen gespeichert. Für Eingabe und Ausgabe sind Bytezahl und SHA-256-Prüfsumme festgehalten. Die Prüfsumme ist ein Fingerabdruck der Datei: Ändert sich auch nur ein Byte, ändert sich die Prüfsumme.
• Für jeden Lauf sind Modus, gegebenenfalls die Zielgröße und die tatsächlich verwendete JPEG-Qualität protokolliert.

Was die drei Modi technisch tun

Im Protokoll und in den Tabellen heißen die Modi lossless, balanced und small. Im Werkzeug findest du sie unter diesen Bezeichnungen: lossless ist Verlustfreie Optimierung, balanced ist Ausgewogen und small ist Kleinere Datei. Verlustfreie Optimierung optimiert nur den Aufbau der Datei, also Objekte und komprimierte Datenströme. Ausgewogen kodiert geeignete Bilder zusätzlich als JPEG mit der Qualitätsstufe 80 neu. Wird eine Zielgröße verfehlt, folgt ein Versuch mit 70. Kleinere Datei beginnt bei Stufe 65 und geht bei verfehltem Ziel auf 50 und dann auf 40. Hast du eine Zielgröße angegeben und erfüllt schon das Original oder die strukturell optimierte Fassung dieses Ziel, ist kein verlustbehafteter JPEG-Versuch nötig. Am Ende wird die kleinste geprüfte Fassung übernommen. Ist keine kleiner als das Original, bleibt das Original. Eine bestimmte Ersparnis ist damit nicht garantiert.

Laut Dokumentation von QPDF 12.2 verkleinert QPDF dabei keine Bildauflösung. Die JPEG-Neukodierung kann aber sichtbare Artefakte erzeugen, und QPDF übernimmt neu kodierte Bilddaten nur, wenn sie kleiner sind. Was das für die Bildqualität bedeutet, erklärt der Ratgeber PDF komprimieren ohne Qualitätsverlust.

Dateien und Prüfsummen zum Nachprüfen

Die folgende Tabelle verknüpft alle Test- und Ergebnisdateien. Vergleiche nach dem Herunterladen die SHA-256-Prüfsumme mit einem Prüfsummenwerkzeug deiner Wahl. Stimmt sie überein, hast du genau die gemessene Datei vor dir. Das englischsprachige Protokoll reproducibility-manifest.json enthält die genauen Aufrufe und Einstellungen aller Läufe.

Ergebnisse: Dateigröße ehrlich dargestellt

Wie stark deine eigene PDF schrumpft, lässt sich aus diesem Test nicht vorhersagen. Das hängt davon ab, was in deiner Datei steckt. Schon die drei Testdateien zeigen die Spannweite: Die kleine Textdatei wurde im Modus lossless um 10,17 Prozent kleiner, die Bilddatei im selben Modus nur um 0,02 Prozent. Erst die JPEG-Neukodierung brachte bei der Bilddatei eine Ersparnis von 86,78 Prozent. Die Tabelle enthält alle neun Läufe, auch die ohne nennenswerte Ersparnis.

Die Ersparnis ist immer aus den tatsächlichen Bytes berechnet: eingesparte Byte geteilt durch die Originalgröße. Beim Lauf mit balanced sind das 1.179.371 von 1.359.079 Byte, also 86,78 Prozent. Für deine eigene Datei rechnest du das mit dem Rechner für die Kompressionsrate nach.

JPEG-Qualität ist keine Ersparnis in Prozent

Die Werte 80, 65 oder 40 sind Einstellungen des JPEG-Encoders und keine Prozentangaben für die Verkleinerung. Qualitätsstufe 80 hat hier 86,78 Prozent eingespart, Stufe 65 dagegen 90,75 Prozent. Bei einer anderen Datei können dieselben Stufen ganz anders ausfallen.

Warum der Fall ohne Ersparnis dazugehört

Ein Test, der nur die beste Ersparnis zeigt, verschweigt einen wichtigen Fall: Was passiert, wenn sich nichts mehr gewinnen lässt? Bei der bereits optimierten Textdatei mit 2.721 Byte lieferte der Modus lossless keine kleinere Fassung. Der Kompressor behielt deshalb das Original: Ausgabe 2.721 Byte, 0 Byte Ersparnis, und Eingabe und Ausgabe haben dieselbe SHA-256-Prüfsumme. Damit ist mit dem echten Kompressionsmodul nachgewiesen, dass du in diesem Fall keine umgeschriebene Datei ohne Nutzen erhältst. Was du dann tun kannst, steht im Ratgeber PDF wird nicht kleiner.

Zielgröße erreicht, verfehlt oder schon erfüllt

• Ziel 250.000 Byte: Schon der erste Versuch mit Stufe 65 lag bei 125.710 Byte. Das Ziel war damit erreicht, und das Ergebnis ist sogar byte-identisch mit dem Lauf ohne Ziel.
• Ziel 128 Byte: Für zwei Seiten mit Bild ist das unrealistisch klein. Auch die letzte Stufe 40 kam nur auf 74.707 Byte. Der Kompressor meldet das Ziel als nicht erreicht und liefert trotzdem eine Datei. Bei dieser Testdatei enthält die gespeicherte Ergebnisdatei mit 74.707 Byte beide Seiten, und die weiter unten beschriebenen Funktionsprüfungen waren bestanden. Die Bilddaten wurden dabei verlustbehaftet neu kodiert. Dass bei jeder anderen Datei alle Inhalte erhalten bleiben, belegt dieser Lauf nicht.
• Ziel 1.359.079 Byte, also genau die Originalgröße: Das Ziel galt als schon erfüllt. Es lief nur die strukturelle, verlustfreie Optimierung. Sie ergab 1.358.764 Byte, dieselbe Größe wie der Lauf mit lossless. Das Bild wurde nicht als JPEG neu kodiert, denn die protokollierten Aufrufe enthalten keine JPEG-Einstellung.

Gleiche Größe, andere Prüfsumme

Die Wiederholung des Laufs mit balanced ergab wieder genau 179.708 Byte, aber eine andere SHA-256-Prüfsumme. Auch der Lauf mit erfülltem Ziel hat dieselbe Größe wie der Lauf mit lossless und trotzdem eine eigene Prüfsumme. Ein möglicher Grund ist, dass beim Schreiben einer PDF zum Beispiel eine neue Dokumentkennung entstehen kann. Die Läufe mit small ohne Ziel und mit Ziel 250.000 Byte stimmten dagegen bis aufs Byte überein. Die Prüfsumme kennzeichnet also eine bestimmte gespeicherte Datei. Wiederholst du einen Lauf, auch im Browser, erhältst du nicht zwingend eine byte-identische Datei, selbst wenn die Größe gleich bleibt.

Darstellung und Funktionen getrennt geprüft

Eine kleinere Datei sagt noch nichts darüber, ob Text, Formular und Link erhalten geblieben sind. Auch eine gute Vorschau beweist das nicht. Deshalb wurden die gespeicherten Dateien mit zwei voneinander unabhängigen Bibliotheken geprüft: pdf-lib liest den gespeicherten inneren Aufbau, und PDF.js 6.4.299 rendert die Seiten und liest Text und Anmerkungen aus. PDF.js lief dafür in einer abgeschotteten Chromium-Instanz der Version 151.0.7922.34. Diese Prüfung der fertigen Dateien ist von der Kompression getrennt, die in Node.js unter Windows 11 gemessen wurde. Eine Kompression im Browser oder auf Mobilgeräten wurde nicht gemessen, und über das Verhalten anderer PDF-Programme sagt die Prüfung nichts aus. Jede Prüfung hat eine eigene Methode und gilt nur für diese Testdateien.

Ein Detail zum Formularfeld: Sein Wert erscheint nicht zuverlässig in der normalen Textextraktion von PDF.js, sondern wurde über die Anmerkungen ausgelesen. Wenn du in einer komprimierten PDF nach einem eingetragenen Formularwert suchst und ihn nicht findest, heißt das deshalb nicht automatisch, dass er fehlt.

Bei balanced und small wurde das Bild verlustbehaftet als JPEG neu kodiert, außer im small-Lauf mit schon vorher erfülltem Ziel. Die dekodierten Inhaltsanweisungen für Text und Linien blieben dabei gleich, die Bilddaten der Textur aber nicht. Auf den gerenderten Seiten der Ergebnisse aus der Bilddatei blieben Position und Ausdehnung des Bildes sowie die Seitendrehung wie im Original. Wichtig, wenn du die Dateien selbst ansiehst: Schon im Original liegt das generierte Bild über mehreren Textzeilen. Diese Überlappung gehört zur Testdatei und ist kein Schaden durch die Kompression. Sie bleibt in den Ergebnissen erhalten. Eine Aussage über die Lesbarkeit jeder Zeile oder eine Qualitätsnote folgt daraus nicht. Ein generiertes Bild mit Textur und Farbverlauf sagt außerdem wenig darüber, wie Fotos, Scans oder kleine Schrift in Scans auf dieselbe Stufe reagieren. Dazu passt der Ratgeber Gescannte PDF verkleinern.

Der Signatur-Platzhalter zeigt nur, dass der Kompressor eine Datei mit Signaturstruktur erkennt und nicht verarbeitet. Laut Kompressionscode werden auch verschlüsselte und zertifizierte Dateien abgewiesen. Ob eine echte Signatur gültig ist, prüft dieser Test nicht, und er umgeht auch keinen Schutz. Mehr dazu im Ratgeber PDF komprimieren mit Signaturen und Formularen.

Grenzen und eigene Nachprüfung

Ist das Tool besser als PDF24 oder Adobe?

Darauf gibt diese Seite keine Antwort. Wir haben keine anderen Programme oder Onlinedienste mit denselben Dateien laufen lassen. Ein Urteil über Qualität, Geschwindigkeit oder Preis im Vergleich wäre daher nicht belegt. Bestenlisten mit Prozentangaben oder Schiebereglern ersetzen so einen Vergleich ebenfalls nicht. Ein fairer Vergleich braucht dieselbe vollständige Eingabedatei, dieselben Seiten, festgehaltene Einstellungen, exakte Bytezahlen und dieselben Funktionsprüfungen für alle Ergebnisse.

So prüfst du deine eigene PDF

1. Behalte eine unveränderte Kopie deines Originals.
2. Öffne den PDF-Kompressor und wähle die Datei aus. Wenn Bilddetails wichtig sind, beginne mit dem verlustfreien Modus.
3. Notiere die genaue Größe in Byte für Original und Ergebnis, zum Beispiel aus den Dateieigenschaften, und berechne die Ersparnis mit dem Rechner für die Kompressionsrate.
4. Starte jeden weiteren Versuch wieder mit dem Original und nicht mit einem bereits komprimierten Ergebnis. Speichere jedes Ergebnis unter einem neuen Dateinamen, damit du nichts überschreibst.
5. Öffne die gespeicherte Datei im Programm, das auch der Empfänger nutzt. Prüfe alle Seiten, suche nach einem bekannten Wort, kontrolliere Formularwerte und Links und sieh dir Bilder und kleine Schrift in Originalgröße an.
6. Ist deine PDF digital signiert, verschlüsselt oder zertifiziert, komprimiere sie nicht mit diesem Werkzeug, sondern kläre den Ablauf mit dem Aussteller.