Warum braucht pdfkonvertieren.de drei Libraries und nicht eine?

Keine der drei Libraries deckt alle Aufgaben ab. `pdf-lib` kann PDFs strukturell verändern, aber keine Seiten rendern. `pdfjs-dist` kann PDFs lesen und rendern, aber nicht editieren. `jsPDF` baut neue PDFs aus Bildern, kann aber keine bestehenden öffnen. Die Kombination ist Standard in fast jedem Browser-PDF-Tool, das mit echten Quelldateien und ohne Server arbeitet.

Sind alle drei Libraries kostenlos für kommerzielle Nutzung?

Ja. `pdf-lib` und `jsPDF` stehen unter MIT-Lizenz, `pdfjs-dist` unter Apache 2.0. Beide Lizenzen erlauben kommerzielle Nutzung, Modifikation und Weiterverteilung ohne Lizenzgebühren. Eine Attribution im Quellcode reicht aus, sie muss nicht im UI sichtbar sein. Die Lizenztexte liegen in den jeweiligen GitHub-Repositories als LICENSE-Datei.

Wer pflegt diese Libraries heute aktiv?

`pdfjs-dist` wird von Mozilla maintained und ist Teil der Firefox-Codebase, Releases erscheinen monatlich. `pdf-lib` wird von Andrew Dillon und einer kleinen Community gepflegt, Release-Frequenz unregelmäßig. `jsPDF` hat aktuell ein Wartungs-Team rund um den parallax-Fork bei GitHub. Alle drei sind Stand 2026 produktiv und haben Millionen wöchentlicher npm-Downloads.

Funktioniert dieser Stack in jedem Browser?

Ja, in jedem modernen Browser ab Chrome 90, Firefox 90, Safari 14 und Edge 90. Die Libraries setzen auf Standard-Web-APIs, vor allem `ArrayBuffer`, `Uint8Array`, `Blob`, `Canvas` und `Web Workers`. Auf älteren Browsern wie Internet Explorer 11 läuft `pdfjs-dist` nur eingeschränkt, da der Worker-Loader fehlt.

Wo liegt der größte Performance-Unterschied?

`pdfjs-dist` ist die rechenintensivste der drei: Canvas-Rendering einer PDF-Seite kostet 100 bis 800 ms pro Seite je nach Inhalt und Auflösung. `pdf-lib` läuft fast latenzfrei, weil es nur PDF-Objekte umschreibt ohne zu rendern. `jsPDF` liegt dazwischen, die meiste Zeit verbraucht bei der Bild-Komprimierung. Daher lagern wir `pdfjs-dist`-Operationen in einen Web Worker aus, um die UI nicht zu blockieren.

pdf-lib, pdfjs-dist, jsPDF: Der Library-Stack hinter pdfkonvertieren.de

Wer im Browser eine PDF-Datei umwandelt, zusammenfügt oder ausliest, nutzt fast immer eine Kombination aus drei JavaScript-Libraries. Wir auf pdfkonvertieren.de setzen sie alle drei ein, weil jede einzelne nur einen Teil des Problems löst. Dieser Artikel beschreibt, was pdf-lib, pdfjs-dist und jsPDF jeweils können, wer sie geschrieben hat und warum genau dieser Stack der De-facto-Standard für clientseitige PDF-Verarbeitung ist.

Drei Libraries, drei Aufgaben

PDF ist ein binäres Container-Format, beschrieben in ISO 32000-1:2008 (entspricht PDF 1.7) und seit ISO 32000-2:2017 in der aktuellen Variante PDF 2.0. Das Format kennt Seiten, Schriftarten, eingebettete Bilder, Vektor-Operatoren, Annotationen, Formularfelder und vieles mehr. Eine einzige Library kann all das nicht performant abdecken, ohne aufgebläht zu werden. In der Praxis hat sich daher eine Arbeitsteilung etabliert.

pdf-lib ist eine Manipulations-Library. Sie öffnet ein bestehendes PDF, liest die Seiten als PDF-Objekte ein, erlaubt Operationen wie das Kopieren, Löschen oder Neuanordnen von Seiten, und schreibt das Ergebnis als neues PDF zurück. Sie rendert nichts, sie zeigt nichts an, sie liest auch keinen Text aus. Sie versteht aber das PDF-Format auf Objekt-Ebene und kann mehrere Eingabe-Dateien zu einem Ausgabe-Dokument verschmelzen, ohne die ursprüngliche Qualität der Seiten zu verlieren.

pdfjs-dist ist eine Renderer- und Parser-Library. Sie öffnet ein PDF, parst die Content-Streams jeder Seite und rendert das Ergebnis entweder auf ein HTML5-<canvas>-Element oder extrahiert die Text-Operatoren als Items mit Position und Glyph-Daten. Sie ist der Browser-Renderer schlechthin, weil sie Teil von Firefox ist und dort als interner PDF-Viewer läuft. Manipulieren kann sie nichts, sie ist reines Lese-Werkzeug.

jsPDF ist eine Generator-Library. Sie startet mit einem leeren PDF und baut Seite für Seite, Text, Bilder und Formen hinzu. Sie ist der Weg, wenn man aus JPG- oder PNG-Bildern oder aus dynamisch generiertem HTML eine PDF-Datei machen möchte. Bestehende PDFs lesen kann sie nicht, dafür braucht es einen der anderen beiden.

pdf-lib im Detail

pdf-lib wurde 2018 von Andrew Dillon gestartet, läuft unter MIT-Lizenz und liegt auf GitHub unter github.com/Hopding/pdf-lib. Die Library ist in TypeScript geschrieben und kompiliert zu reinem JavaScript ohne Browser-Abhängigkeiten. Sie läuft genauso in Node.js wie im Browser und in Deno oder Bun. Auf npm verzeichnet das Paket aktuell mehrere Millionen wöchentlicher Downloads.

Die Kern-API arbeitet mit der Klasse PDFDocument. Über PDFDocument.load(bytes) lädt man ein bestehendes PDF aus einem ArrayBuffer oder Uint8Array, mit PDFDocument.create() legt man ein leeres an. Über copyPages(srcDoc, indices) werden Seiten aus einem Quelldokument geklont und können dann mit addPage(copiedPage) ans Zieldokument angehängt werden. Das ist exakt der Mechanismus hinter unserem Zusammenfügen-Tool: Nutzer laden mehrere PDFs hoch, wir öffnen jedes einzeln, kopieren alle Seiten in der gewünschten Reihenfolge in ein neues PDFDocument und speichern das Ergebnis mit doc.save() als neues Uint8Array zurück.

Was pdf-lib nicht kann, ist genauso wichtig wie das, was es kann: Es kann keine Seiten in Pixel umwandeln, keinen Text extrahieren, keine OCR-Funktionalität liefern und auch keine PDF-Vorschau auf einem Canvas darstellen. Für diese Aufgaben braucht es pdfjs-dist.

pdfjs-dist im Detail

pdfjs-dist ist die npm-Distribution von Mozillas pdf.js-Projekt. Das Projekt wurde im Juni 2011 von Andreas Gal und einem kleinen Mozilla-Team gestartet, mit dem Ziel, PDF im Browser ohne Adobe-Reader-Plugin anzuzeigen. Seit Firefox 19 im Februar 2013 ist pdf.js der Default-PDF-Renderer in Firefox. Die Library steht unter Apache 2.0 und liegt auf GitHub unter github.com/mozilla/pdf.js. Wer sie außerhalb von Firefox nutzen möchte, installiert das npm-Paket pdfjs-dist, das die kompilierten Builds plus Worker-Files enthält.

Die zentrale API ist getDocument(src), was eine Promise mit einem PDFDocumentProxy zurückgibt. Über diesen Proxy fragt man einzelne Seiten ab, etwa mit doc.getPage(1), was wiederum einen PDFPageProxy liefert. Auf der Seite ruft man getViewport({ scale }) auf und rendert mit page.render({ canvasContext, viewport }) auf ein HTML5-Canvas. Die Skalierung steuert die DPI: scale 1 entspricht 72 DPI, scale 4 entspricht 288 DPI.

Für Text-Extraktion gibt es page.getTextContent(), was ein Objekt mit einem items-Array zurückliefert. Jedes Item enthält den extrahierten Text (str) und eine 6-elementige Transform-Matrix (transform) mit Position und Skalierung im PDF-Koordinatensystem. Daraus lässt sich rekonstruieren, in welcher Reihenfolge und mit welchen Zeilenumbrüchen die Glyphen ursprünglich gesetzt waren.

pdfjs-dist läuft standardmäßig in einem Web Worker, um den Haupt-Thread nicht zu blockieren. Der Worker wird aus einer separaten Datei pdf.worker.min.mjs geladen, die im npm-Paket mitgeliefert wird. In Astro-Builds muss diese Datei in den public/-Ordner kopiert oder über import.meta.url referenziert werden.

jsPDF im Detail

jsPDF wurde ursprünglich von James Hall gestartet und liegt heute beim parallax-Fork unter github.com/parallax/jsPDF. Die Library steht unter MIT-Lizenz und gehört zu den ältesten reinen JavaScript-PDF-Generatoren. Anders als pdf-lib öffnet sie keine bestehenden PDFs, sondern erzeugt von Grund auf neue.

Das typische Workflow auf pdfkonvertieren.de: Der Nutzer wählt JPG- oder PNG-Bilder aus. Wir starten ein neues jsPDF-Dokument mit new jsPDF({ unit: 'mm', format: 'a4' }), fügen pro Bild eine Seite via doc.addPage() hinzu und platzieren das Bild mit doc.addImage(dataUrl, 'JPEG', x, y, width, height, undefined, 'MEDIUM'). Der letzte Parameter steuert die JPEG-Komprimierung im PDF und bestimmt die Dateigröße des Ergebnisses. Die Seitengröße rechnen wir vorher in Millimeter um, damit das Bild proportional auf die Seite passt und der weiße Rand symmetrisch bleibt.

jsPDF unterstützt verschiedene Seitenformate (a4, letter, legal, custom in Millimetern), Orientierung (portrait, landscape) und einige Schriftarten (Helvetica, Times, Courier) eingebettet. Mit Plugins lassen sich auch TTF-Fonts laden, das ist aber selten nötig, wenn nur Bilder ins PDF gehen.

Wie die drei zusammenspielen

Drei Libraries decken Manipulation, Rendering und Generation getrennt ab

Ein konkretes Beispiel macht den Stack greifbar. Beim Konvertieren PDF zu JPG passiert Folgendes: Der Nutzer wählt eine PDF-Datei. Wir lesen sie als ArrayBuffer ein. pdfjs-dist.getDocument(buffer) öffnet das Dokument. Für jede Seite holen wir getViewport({ scale: 2 }) und rendern via page.render({ canvasContext, viewport }) auf einen Off-Screen-Canvas. Der Canvas wird via toBlob('image/jpeg', 0.92) zu einem JPG-Blob, den der Nutzer als ZIP-Datei herunterladen kann. pdf-lib und jsPDF sind hier nicht beteiligt.

Beim Zusammenfügen mehrerer PDFs läuft es anders: Wir öffnen jedes Quelldokument mit PDFDocument.load(bytes) von pdf-lib, kopieren alle Seiten über copyPages ins Ziel und speichern mit save(). Hier ist nur pdf-lib im Spiel, kein Rendering nötig.

Beim Konvertieren Bilder zu PDF kommt jsPDF zum Einsatz: Wir lesen die Bilder als DataURL ein, berechnen die optimale Seitengröße und Position über die Bild-Dimensionen und fügen sie via addImage auf separate Seiten ein.

Memory-Management und Web Worker

Browser-PDF-Tools haben einen klaren Engpass: den Arbeitsspeicher. Eine PDF-Datei mit 200 Seiten und vielen eingebetteten Bildern kann als ArrayBuffer mehrere hundert Megabyte beanspruchen, das gerenderte Canvas-Bild noch mal so viel. Wir achten in allen Engines bewusst darauf, Speicher zeitnah freizugeben. Nach dem Encoding eines Canvas zu JPG setzen wir canvas.width = 0 und canvas.height = 0, was den Browser zur Garbage-Collection des Canvas-Backings zwingt. Bei pdfjs-dist rufen wir page.cleanup() und am Ende doc.destroy(), damit der Worker seinen internen Cache leert.

Für lange Konvertierungs-Operationen lagern wir die rechenintensiven Teile in einen Web Worker aus. pdfjs-dist bringt seinen eigenen Worker mit (pdf.worker.min.mjs). pdf-lib hat keinen eigenen Worker, lässt sich aber leicht in einen eigenen Worker einbauen, weil die API rein funktional arbeitet und keine DOM-Zugriffe braucht. Bei kleinen Konvertierungen (eine A4-Seite) lohnt sich der Worker-Overhead nicht, bei mehr als zehn Seiten ist er klar im Vorteil. Wir messen Eingabe-Größe und Seiten-Zahl und entscheiden dynamisch, ob wir den Worker einsetzen.

Versions-Kompatibilität und Updates

Alle drei Libraries entwickeln sich aktiv weiter. pdfjs-dist hat einen monatlichen Release-Zyklus, Major-Versionen erscheinen etwa alle zwei Jahre. Bei einem Major-Update können API-Signaturen sich ändern: ab Version 4 (Anfang 2024) wird zum Beispiel der Worker nicht mehr automatisch geladen, sondern muss explizit gesetzt werden. pdf-lib ist konservativer: API-Brüche sind selten, die letzte größere Änderung war 2021. jsPDF hat seit dem Maintenance-Übergang zu parallax 2018 eine stabile API.

Wir aktualisieren die Libraries vierteljährlich. Vor jedem Update läuft unsere komplette Test-Suite, die für jedes Tool die Konvertierungs-Ergebnisse mit Referenz-Dateien vergleicht. Bricht ein Test, untersuchen wir, ob es ein echter Bug ist oder ein gewolltes Verhalten der neuen Version, und passen den Test entsprechend an oder pinnen die alte Version, bis ein Fix verfügbar ist.

Warum dieser Stack Standard ist

Die Kombination pdf-lib + pdfjs-dist + jsPDF ist in der Branche so verbreitet, weil sie drei wichtige Kriterien erfüllt: erstens vollständige Browser-Kompatibilität ohne Server-Komponente, zweitens permissive Open-Source-Lizenzen (MIT und Apache 2.0), die kommerzielle Nutzung erlauben, drittens aktive Wartung mit kontinuierlichen Security-Patches. Alternative Libraries wie pdfkit laufen nur in Node.js, Hummus.js ist nicht mehr maintained, und kommerzielle SDKs wie Foxit oder PDFTron kosten je nach Volumen mittlere fünfstellige Lizenzgebühren pro Jahr.

Für ein Browser-only-Tool wie pdfkonvertieren.de gibt es zur Drei-Library-Kombination derzeit keine ernsthafte Alternative. Server-basierte Konvertierer (Smallpdf, ILovePDF, PDF24) nutzen oft die kommerzielle iText-Java-Library oder eine Variante von Ghostscript. Beide laufen nicht im Browser. Damit bleibt für unseren Anwendungsfall der vorgestellte JavaScript-Stack die einzige sinnvolle Wahl.

Was hängenbleibt

Jede Konvertierung auf pdfkonvertieren.de läuft über eine von drei Libraries oder eine Kombination daraus. pdf-lib (MIT, Andrew Dillon, 2018) manipuliert bestehende PDFs strukturell. pdfjs-dist (Apache 2.0, Mozilla, 2011) rendert und liest PDFs aus. jsPDF (MIT, James Hall) generiert neue PDFs aus Bildern. Alle drei sind kostenlos kommerziell nutzbar, laufen vollständig im Browser ohne Server-Komponente und werden aktiv maintained. Wer ein Browser-PDF-Tool baut, kommt aktuell an dieser Kombination nicht vorbei.