Decydujący przewodnik po narzędziach do konwersji HTML do PDF w 2026

Jak silniki renderowania definiują możliwości narzędzi PDF

Jednym z najważniejszych czynników przy wyborze narzędzia HTML na PDF jest jego silnik renderujący. Każda inna funkcja, wsparcie CSS, wykonanie JavaScript, wierność renderowania — wynika z tej decyzji architektonicznej.

Narzędzia oparte na Chromium/Blink (Puppeteer, Playwright, IronPDF, Gotenberg, PDFCrowd, PDFShift, Selenium) wykorzystują silnik przeglądarki Google. Ładują stronę identycznie jak Chrome, wspierają pełny CSS3 (Flexbox, Grid, zmienne, zapytania mediów) i wykonują cały nowoczesny kod HTML. Kompromis to zużycie zasobów: ~85–200 MB RAM na konwersję przy jednoczesnym obciążeniu, obrazy Dockera o rozmiarze 1,5–2 GB i 5–15 sekund na zimne uruchomienia w środowiskach bezserwerowych.

Niestandardowe silniki CSS-to-PDF (PrinceXML, PDFreactor, Antenna House, WeasyPrint, iText pdfHTML) analizują HTML i CSS za pomocą dedykowanych rendererów. Doskonalą się w CSS Paged Media—biegające nagłówki, sekcje stopki, przypisy dolne i ramki marginesowe, funkcje, których zasadniczo brakuje w przeglądarkach internetowych. PrinceXML wprowadził to podejście w 2003; jego przewodniczący Håkon Wium Lie współtworzył sam CSS. PDFreactor oferuje najlepsze wsparcie JavaScript wśród silników niestandardowych (ECMAScript 2025 za pośrednictwem GraalJS). Antenna House przewodzi w umiędzynarodowieniu (80+ języków, 30+ skryptów) i wydajności surowej za pomocą natywnego silnika C/C++.

Programowe budownice (PDFKit, pdfmake, jsPDF) konstruują pliki PDF z kodu, zamiast z bezpośredniego wejścia HTML. Produkują wyjście wektorowe z wybieralnym tekstem, ale wymagają od programistów definiowania układów programowo—całkowicie bez analizowania HTML/CSS. Narzędzia do zrzutów ekranowych po stronie klienta (html2pdf.js) przechwytują przeglądarkowo-renderowany DOM jako obrazy rastrowe, produkując niedosyłalne, nieprzeszukiwalne dokumenty z istotnymi ograniczeniami wielkości stron i jakości.

Kompletny wykres porównania narzędzi

Poniższa tabelka destyluje najbardziej istotne cechy decyzji dla wszystkich 23 narzędzi. Szczegółowa analiza każdego następuje w kolejnych sekcjach.

IronPDF: Konwertuj pliki HTML na PDF z łatwością dzięki tej wyróżniającej się bibliotece

IronPDF zasługuje na pogłębioną analizę, ponieważ zajmuje unikalną pozycję: oparty na silniku Chromium pakiet renderujący w natywnej bibliotece .NET z niezwykle szerokim zestawem narzędzi PDF. Gdzie Puppeteer wymaga od programistów instalacji i dokowowania oddzielnych bibliotek do szyfrowania, podpisów cyfrowych czy manipulacji formularzami, IronPDF łączy to wszystko w pojedynczym pakiecie NuGet.

Architektura renderowania zawiera dostosowany, zoptymalizowany silnik Chrome, który pozostaje gotowy do kolejnych renderów, eliminując proces uruchamiania osobnego procesu dla każdego PDF, co czyni surowe Puppeteer kosztownym na dużą skalę. IronPDF twierdzi, że oferuje wydajność 5–20x szybszą niż rozwiązania oparte na sterownikach sieciowych w scenariuszach wysokiego obciążenia. Recenzje G2 potwierdzają "raporty 100+ stron z dokładnością do piksela" i pełne wierność CSS.

Ergonomia API jest naprawdę minimalna dla każdego pliku HTML. Wzór podstawowy to dwie linie C#:

var pdf = new ChromePdfRenderer().RenderHtmlAsPdf("<h1>Hello</h1>");

pdf.SaveAs("output.pdf");

var pdf = new ChromePdfRenderer().RenderHtmlAsPdf("<h1>Hello</h1>");

pdf.SaveAs("output.pdf");

Dim pdf = (New ChromePdfRenderer()).RenderHtmlAsPdf("<h1>Hello</h1>")

pdf.SaveAs("output.pdf")

Skalowanie konfiguracji jest czyste: RenderingOptions udostępnia przełączanie typu mediów CSS, strategie oczekiwania na JavaScript, wstrzykiwanie niestandardowego CSS i kontrolę responsywności przez PaperFit. Szerokość zestawu narzędzi to główny wyróżnik. IronPDF wspiera łączenie, dzielenie, kopiowanie/usuwanie plików, szyfrowanie AES-256, podpisy cyfrowe X.509, trwałe wyodrębnianie, znakowanie wodne oparte na HTML, zgodność stronowania PDF/A, dostępne wyjście PDF/UA i tworzenie AcroForm z elementów HTML

Narzędzia do automatyzacji sieci dzielą się mocami i ograniczeniami Chromium

Puppeteer, Playwright, Headless Chrome CDP, Selenium i Gotenberg ostatecznie wywołują komendę CDP Page.printToPDF Chromium. Różnią się poziomem abstrakcji, wsparciem językowym i ergonomią operacyjną.

Puppeteer (Google, Apache 2.0) pozostaje najdojrzalszą opcją Node.js z 31.1 tys. gwiazdek na GitHub. Jego API page.pdf() ujawnia format papieru, skalę (0.1–2x), marginesy, szablony nagłówków/stopki HTML z klasami wstrzykiwania (pageNumber, totalPages, date), drukowanie tła, zakresy stron i eksperymentalne generowanie konturu dokumentu. Studium przypadku Carriyo udokumentowało 10 000 PDF/dzień na AWS Lambda. Metoda page.createPDFStream() obsługuje duże dokumenty bez awarii pamięci. Puppeteer średnio 7.84 sekundy dla 10 PDF w testach, około 3x szybciej niż wkhtmltopdf dla tej samej treści.

Playwright (Microsoft, Apache 2.0) oferuje niemal identyczne możliwości PDF, ale dodaje oficjalne wsparcie wielojęzykowe (JavaScript, Python, Java, .NET) i wbudowane automatyczne oczekiwanie, które redukuje niestabilność w porównaniu z manualnym waitForSelector Puppeteera. Wersja 1.42+ dodała generowanie konturu/zakładek PDF z struktury nagłówków. Generowanie PDF jest tylko dla Chromium, nie działa z przeglądarkami Firefox ani WebKit Playwrighta. Testy pokazują, że średni czas na Playwright wynosi 4.513 s, a na Puppeteer 4.784 s dla przepływów roboczych wymagających wielu nawigacji.

Gotenberg opakowuje Chromium (i LibreOffice dla dokumentów Office) w bazujące na Go Docker HTTP API na licencji MIT. Jest to architektura referencyjna dla PDF jako mikroserwisu: bezstanowa, niezależna od języka dzięki multipart/form-data i dostępna jako zoptymalizowane obrazy dla Cloud Run i AWS Lambda. Dodaje unikalnie szyfrowanie PDF (AES-256 za pomocą QPDF), zgodność z PDF/A (1a, 2b, 3b), operacje scalania/dzielenia oraz edycję metadanych PDF, które żadne inne narzędzie oparte na Chromium nie oferuje natywnie. Współbieżność jest ograniczona do 6 jednoczesnych konwersji na instancję (konfigurowalne), z poziomym skalowaniem przez dodatkowe kontenery.

Headless Chrome CDP jest najniższym poziomem opcji, zerowe obciążenie biblioteki, tylko binary Chrome i klient CDP w dowolnym języku (Go, Python, Ruby, Elixir). Tryb CLI (chrome --headless --print-to-pdf) jest wycofywany na rzecz API CDP. Kompromisem jest zarządzanie cyklem życia procesu Chrome, procesami zombie i implementacja własnych strategii oczekiwania manualnie.

Selenium + PDF przeglądarki to najsłabsza opcja generowania PDF. Jego standardowe API PrintsPage ma ograniczone opcje; pełne szablony nagłówków i stopek wymagają mostka CDP (driver.execute_cdp_cmd("Page.printToPDF", {...})), który działa tylko z Chromium i sam jest tymczasowy (przejście do WebDriver BiDi). Dokumentacja o pakiecie selenium-print wyraźnie ostrzega: "jeśli twoim priorytetem jest wydajność, to nie jest biblioteka dla ciebie."

Żadne z tych narzędzi nie produkuje wypełnialnych formularzy PDF — funkcjonalność drukowania do PDF Chromium splaszcza wszystkie elementy formularzy. Żadne nie wspiera szyfrowania PDF, podpisów cyfrowych ani redakcji natywnie. Do tych funkcji wymagana jest post-obróbka za pomocą zewnętrznych biblioteki (pdf-lib, QPDF, iText) — lub użyj Gotenberga, który zintegrował te narzędzia.

Komercyjne silniki CSS doskonale nadają się do publikacji paginowanych dokumentów PDF

PrinceXML, PDFreactor i Antenna House wymagają wysokich cen, ponieważ implementują specyfikacje W3C CSS Paged Media, których przeglądarki internetowe po prostu nie mają. Obsługują ustawienia wielkości strony, skrzynki marginesowe po lewej, przypisy dolne, strony nazwane i automatyczne generowanie spisów treści.

PrinceXML ($3,800/serwer jednorazowe, $495/desktop) jest złotym standardem. Jego niestandardowy silnik, napisany w Mercury, produkował najwyższą jakość wyjściową CSS Paged Media od 2003 roku. Prince wspiera Flexbox (od v12, 2018) i CSS Grid (od v16, ~2024, z krzyżowaniem się wciąż dojrzewającym). JavaScript jest ograniczony do ES5 tylko — brak funkcji strzałkowych, Obietnic czy async/await. Wspiera PDF/A-1a/1b/3a/3b, PDF/UA-1, PDF/X-1a/3/4, szyfrowanie RC4 (40/128-bitowe), ale nie wspiera podpisów cyfrowych (to długoletnie zaniechanie). Darmowa niekomercyjna licencja ze znakiem wodnym jest dostępna do celów rozwojowych.

PDFreactor ($1 908/rok Pro subskrypcja) jest technicznie najbardziej zaawansowany. Integracja z GraalJS zapewnia wsparcie ECMAScript 2025 (wymagające Java 20+), czyniąc go jedynym niestandardowym silnikiem CSS z pełnym nowoczesnym JavaScript. Wspiera CSS Regions, CSS Shapes, siatki bazowe oraz najszerszy zestaw wariantów PDF/A (1a przez 3u). Co najważniejsze, zawiera wbudowane podpisy cyfrowe — czego Prince brakuje. Wdrożenie odbywa się przez JAR Java, wbudowaną usługę sieciową Jetty lub kontener Docker. Klienci Enterprise to m.in. Dell Technologies i Deutsche Post (500 000+ pracowników).

Antenna House Formatter ($5,000/serwer wieczysty dla XSL-FO, $1 250/samodzielne dla CSS) jest unikalny jako podwójny silnik XSL-FO i CSS. Jego natywna implementacja C/C++ dostarcza najszybszą wydajność surową z najmniejszym zużyciem pamięci. Obsługuje 80+ języków i 30+ skryptów — bezkonkurencyjny w zakresie umiędzynarodowienia. Jednak nie wspiera JavaScript w ogóle, a CSS Grid nie jest wspierany. Jego główna publiczność to XML-centryczne przepływy publikacyjne (DITA, DocBook), gdzie XSL-FO zapewnia bardziej szczegółową kontrolę niż CSS.

Narzędzia ekosystemu Java rozciągają się od Enterprise do lekkich

iText pdfHTML jest najbardziej zaawansowaną opcją Java, wspierającą Flexbox (kompleksowo od 2025), CSS Grid (od 2024), nagłówki/stopy CSS Paged Media i konwersję HTML na AcroForm. Jego głównym ograniczeniem jest licencjonowanie: AGPL v3 wymaga otwartego pozyskania całej aplikacji, jeśli ją rozpowszechniasz lub oferujesz jako usługę sieciową. Licencje komercyjne wahają się od ~$10,000/rok (małe wdrożenia) do $210,000+/rok (Enterprise), ze średnią branżową ~ $45,000/rok na dane Vendr. iText nie wykonuje JavaScript, to tylko statyczny parser HTML/CSS.

OpenHTMLtoPDF i Flying Saucer są alternatywami licencjonowanymi na LGPL, które można swobodnie używać w oprogramowaniu własnościowym. Obie są ograniczone do CSS 2.1 — brak Flexbox, brak Grid — i nie wykonują JavaScript. Oryginalne repozytorium OpenHTMLtoPDF (danfickle/openhtmltopdf, 2.1k gwiazdek) zostało porzucone około ~2022; aktywny fork społecznościowy na io.github.openhtmltopdf (Maven Central, v1.1.31, wrzesień 2025) zmigrował do PDFBox 3.x. Flying Saucer (2.2k gwiazdek) jest nadal aktywnie utrzymywane przez @asolntsev (v10.0.6, grudzień 2025), ale teraz wymaga Java 21+ dla najnowszej wersji. Oba narzędzia wymagają dobrze sformułowanego wejścia XHTML, nie mogą przetworzyć dowolnego "dzikiego" HTML.

⚠ Uwaga dotycząca jakości źródła: Twierdzenia o wsparciu CSS dla OpenHTMLtoPDF i Flying Saucer pochodzą głównie z README projektów i raportów społeczności. Nie ma matryc wsparcia CSS ani niezależnych walidacji stron trzecich dla żadnego z narzędzi. Twierdzenia dotyczące wydajności są zgłaszane samodzielnie bez niezależnych testów.

Narzędzia JavaScript po stronie klienta dobrze służą w wąskich przypadkach użycia

pdfmake (12,2 tys. gwiazdek, 1,1M+ pobrań tygodniowo npm) jest najsilniejszą opcją po stronie klienta dla strukturalnych dokumentów. Używa deklaratywnej definicji dokumentu JSON — nie HTML — z wbudowanym automatycznym stronicowaniem, powtarzaniem nagłówków tabel na stronach, dynamicznymi nagłówkami/stopkami z licznikiem stron oraz wyjściem wektorowym (szukalne, wybieralne teksty). Obsługuje PDF/A (beta) i szyfrowanie. Krzywa uczenia to jego deklaratywna składnia, która wymaga ponownego wyrażania treści, która może już istnieć jako HTML.

PDFKit (10,5 tys. gwiazdek, 1,2M+ pobrań tygodniowo) zapewnia niskopoziomową imperatywną kontrolę, API podobne do płótna dla precyzyjnego rozmieszczenia. Jego API strumieniowe sprawia, że jest wydajne pamięciowo dla dużych dokumentów po stronie serwera. Obsługuje tworzenie AcroForm, dostępność PDF/UA i szyfrowanie RC4/AES. Jednak nie posiada parsowania HTML/CSS ani wbudowanego wsparcia tabel (wymagającego wtyczek jak pdfkit-table).

jsPDF (31.1k gwiazdek, ~2.5M pobrań tygodniowo) jest najpopularniejsze według pobrań. Jego metoda .html() używa html2canvas do przechwytywania DOM jako obrazów rastrowych, produkując nieprzeszukiwalne, niedosyłalne PDF-y o dużych rozmiarach plików. Jego wtyczka AcroForm może utworzyć wypełnialne pola formularzy programowo, ale nie z elementów formularzy HTML. Limit rozmiaru płótna (~16,384px wysokości) powoduje puste strony dla długich dokumentów.

html2pdf.js (4,8 tys. gwiazdek) w opakowuje jsPDF + html2canvas w najprostsze możliwe API: html2pdf(element). Wyjście to wyłącznie obrazy rastrowe. Ograniczenie rozmiaru płótna jest jego najkrytyczniejszym błędem — dokumenty przekraczające ~16,384px renderują się jako całkowicie puste strony (problem GitHub #19). Posiada 462 otwarte problemy, działa tylko w przeglądarkach (brak Node.js) i produkuje niedostępne wyjście.

Chmurowe API zamieniają kontrolę na prostotę operacyjną

DocRaptor ($15–$1 000+/mies.) jest jedynym API wykorzystującym PrinceXML, co daje mu niezrównane wsparcie dla Paged Media CSS, automatyczną konwersję HTML na wypełnialne PDF i wyjście dostępne WCAG/Section 508. Oferuje 99.99% czasu działania SLA, zgodność z SOC 2 i HIPAA, 30 jednoczesnych dokumentów niezależnie od planu i nielimitowane darmowe testowe dokumenty ze znakami wodnymi. Kompromisem są ograniczenia Prince do JavaScript ES5 i wdrożenie tylko chmurowe.

Nutrient Document Engine (dawniej PSPDFKit, przemianowany w 2024 po uzyskaniu 100 mln € od Insight Partners) jest najbardziej wszechstronną platformą — nie tylko HTML-na-PDF, ale pełnym SDK do przetwarzania dokumentów obejmującym Web, iOS, Android, .NET i więcej. Oferuje certyfikację SOC 2 Typ II, zgodność WCAG 2.2 AA, redakcji wspomaganą przez AI i kryptograficzne podpisy cyfrowe. Dostępne jest wdrożenie Docker hostowane samodzielnie. Ceny API chmury DWS rozpoczynają się od $67/miesiąc (1 000 kredytów, z kosztem 0.5 kredytu za każdy HTML-na-PDF). Licencjonowanie SDK jest niejasne, wymaga kontaktu z działem sprzedaży, a kontrakty na Enterprise rzekomo osiągają znaczne roczne zobowiązania.

PDFShift wyróżnia się prostotą: integracja trzech linii, hojna darmowa warstwa (50 konwersji/miesiąc), 50 równoczesnych konwersji na wszystkich planach, prywatność pierwsza polityka w zakresie przetwarzania danych (brak przechowywania dokumentów) i dostępność HIPAA BAA. Cena wynosi $9–$99+/miesiąc. Brak CSS Paged Media, wypełnialnych formularzy i wsparcia dla dostępnych PDF.

PDFCrowd używa Chromium z cenami opartymi na kredytach związanymi z rozmiarem pliku wyjściowego (1 kredyt = 0.5 MB wyjścia), co czyni koszty nieprzewidywalne dla dokumentów o zmiennej wielkości. Limity szybkości wynoszą od 15–360 konwersji/minutę w zależności od planu. Brakuje wsparcia dla dostępnych/zatagiowanych PDF i nie posiada publicznego SLA czasu działania.

APITemplate.io ($19–$179/miesiąc na plany tylko PDF) koncentruje się na generowaniu opartym na szablonach z edytorem WYSIWYG, integracjami Zapier/Make.com i regionalnymi punktami końcowymi API (USA, UE, Singapur, Australia). Jest zoptymalizowane dla powtarzalnych typów dokumentów (faktury, certyfikaty, raporty) zamiast dowolnej konwersji HTML.

wkhtmltopdf jest krytycznym zagrożeniem bezpieczeństwa, które wymaga zastąpienia

wkhtmltopdf został zarchiwizowany na GitHub w styczniu 2023 i oznaczony jako nieutrzymywany od lipca 2024 przez administratorów. Jego ostatnia wersja (0.12.6, czerwiec 2020) używa silnika Qt WebKit z około 2012 roku z brakiem łatek bezpieczeństwa od momentu archiwizacji. Największe zagrożenie, CVE-2022-35583 (CVSS 9.8 Krytyczne), umożliwia atak na serwer przez wprowadzenie zdalnych poleceń: atakujący wstrzykują iFrame do dostarczonego przez użytkownika HTML mogą uzyskać dostęp do wewnętrznych zasobów sieciowych, w tym metadanych instancji AWS EC2 pod adresem 169.254.169.254, potencjalnie prowadząc do pełnego przejęcia infrastruktury. CVE-2020-21365 (CVSS 7.5) umożliwia przejście do katalogu i odczyt lokalnych plików.

Strona statusu głównego twórcy wkhtmltopdf ostrzega: "Nie używaj wkhtmltopdf z jakimkolwiek niezaufanym HTML". CiviCRM wydało CIVI-PSA-2024-01 zalecającą natychmiastowe usunięcie. Pantheon usunął go z PHP Runtime Gen 2 w 2025. Pomimo tego, wkhtmltopdf nadal jest osadzone w bibliotekach opakowań we wszystkich głównych ekosystemach językowych (pdfkit w Pythonie, wicked_pdf w Ruby, KnpSnappy w PHP, DinkToPdf w .NET).

Ścieżki migracji: Puppeteer/Playwright dla pełnego wykonania JavaScript (najbliższy funkcjonalny odpowiednik), WeasyPrint dla stosów w Pythonie nie potrzebujących JS, Gotenberg dla architektur mikroserwisowych lub DocRaptor/PrinceXML dla potrzeb CSS Paged Media.

Testy wydajności ujawniają wyraźne kompromisy w zasobach

Niezależne testy od Kyotu Technology i hardkoded.com dostarczają porównań ilościowych:

Obrazy Docker WeasyPrint są dramatycznie mniejsze w przedziale 200–400 MB, a silnik renderujący nie ma zależności od Chromium. Jednak WeasyPrint jest znany ze swojej wolności dla skomplikowanych dokumentów — PDF o 52 stronach zajął około 100 sekund w jednym teście, a duże tabele (5 000+ wierszy) mogą konsumować 1,4+ GB RAM.

Dla bezserwerowych, krytycznym miernikiem jest czas startu na zimno. Funkcje Lambda oparte na Chromium doświadczają 5-15 sekund startu na zimno z powodu dekompresji binarnej. Używanie @sparticuz/chromium-min (~50 MB skompresowane) z Puppeteer-core mieści się w 250 MB limicie Lambdy i zmniejsza rozmiar pakietu z ~41 MB do ~769 KB. Zapewniona współbieżność obniża starty na zimno do około 400 ms, ale dodaje koszt. Pamięć Lambda powinna wynosić w minimalnym 1 024 MB, idealnie 1 600 MB dla niezawodnego generowania PDF w Chromium.

Możliwości bezpieczeństwa znacznie różnią się w poszczególnych narzędziach

Tylko iText i IronPDF zapewniają pełen zestaw zabezpieczeń obejmujący szyfrowanie, podpisy cyfrowe i redakcję. iText Suite 9.5 wprowadza algorytmy podpisu odporne na obliczenia kwantowe w celu zabezpieczenia na przyszłość. Wśród API chmurowych DocRaptor (SOC 2, HIPAA) i Nutrient (SOC 2 Type II, HIPAA, WCAG 2.2) przewodzą w certyfikacjach zgodności.

Pułapki wdrożeniowe, które każda drużyna powinna przewidzieć

Czcionki są przyczyną nr 1 różnic w renderowaniu między rozwojem a produkcją. Minimalne obrazy Docker nie mają żadnych czcionek, co skutkuje tofu (□) dla tekstu spoza ASCII. Rozwiązaniem jest instalacja kompleksowych pakietów czcionek — rodzina czcionek Noto pokrywa niemal każdy system pisma. Dla wsparcia CJK niezbędne są czcionki noto-cjk. Własne czcionki należy skopiować do /usr/local/share/fonts/, a następnie uruchomić fc-cache -f -v.

Sandbox w Chromium w Dockerze to drugi problem wdrożeniowy. Chromium wymaga nazw przestrzeni jądra Linuksa, których kontenery Docker często nie mają, co skutkuje błędami Running as root without --no-sandbox is not supported. Poprawnym rozwiązaniem jest utworzenie użytkownika innego niż root (useradd -r pptruser); szybkim rozwiązaniem jest --no-sandbox, co zmniejsza bezpieczeństwo i powinno być używane tylko do zaufanych treści.

Gromadzenie pamięci jest cichym zabójcą w długo działających procesach Chromium. Pamięć zwiększa się przy każdej konwersji, co ostatecznie wywołuje awarie OOM. Krytyczne środki zaradcze obejmują: zwiększanie pamięci współdzielonej Docker (--shm-size=512M, ponieważ domyślna 64 MB powoduje awarie), używanie --disable-dev-shm-usage, ponowne uruchamianie instancji przeglądarki po N konwersjach (Gotenberg robi to automatycznie co 100) oraz korzystanie z dumb-init lub Docker --init do oczyszczania procesów zombie. Pojedyncza tabela HTML z 50 000 wierszy może zużywać 10+ GB RAM w Chromium.

Synchronizacja JavaScript powoduje niekompletne PDFy, gdy dynamiczna zawartość nie zakończyła ładowania. Użyj waitUntil: 'networkidle0' (czeka, aż liczba połączeń sieciowych spadnie do zera przez 500 ms) lub page.waitForSelector('.data-loaded') dla jawnej gotowości elementu. Gotenberg łagodzi to przez oczekiwanie na zdarzenia DomContent, Load, NetworkIdle i LoadingFinished domyślnie, dodając ~2 sekundy bazowego opóźnienia, ale zapewniając kompletność.

Jakie narzędzie do jakiego przypadku użycia

Faktury i wyciągi: WeasyPrint (stacki Pythona — lekkie, doskonałe CSS Paged Media, brak nadmiaru Chromium), Gotenberg (mikroserwis niezależny od języka) lub pdfmake (strukturalne dokumenty po stronie klienta). Dla .NET, IronPDF zapewnia najbardziej ergonomiczną API.

Raporty i pulpity nawigacyjne z wykresami: Puppeteer lub Playwright — tylko pełne silniki przeglądarek mogą natywnie wykonawczo D3.js, Chart.js lub Plotly. WeasyPrint nie może renderować wykresów generowanych przez JavaScript. Silnik Chromium IronPDF obsługuje to wewnątrz aplikacji .NET bez uruchamiania zewnętrznych procesów.

Renderowanie SPA do PDF: Puppeteer lub Playwright to jedyne realistyczne opcje. Nowoczesne frameworki (React, Angular, Vue) wymagają pełnego uruchomienia przeglądarki. Konfiguracja waitUntil jest kluczowa dla zapewnienia załadowania całej asynchronicznej zawartości.

Zgodność i bezpieczeństwo (PDF/A, podpis cyfrowy, szyfrowanie): iText (najbardziej wszechstronne, ale drogie), IronPDF (.NET, szerokie funkcje bezpieczeństwa) lub PDFreactor (Java, wbudowane podpisywanie). Narzędzia oparte na Chromium wymagają zewnętrznego przetwarzania końcowego dla dowolnych funkcji bezpieczeństwa.

Bezserwerowe i kontenery: Gotenberg (przeznaczone do kontenerów, licencja MIT, obrazy Cloud Run/Lambda), lub Puppeteer-core + @sparticuz/chromium-min dla AWS Lambda (50 MB skompresowane, mieści się w limitach).

Wydawnictwa jakości druku: PrinceXML lub DocRaptor (API) — nic nie zbliża się do ich CSS Paged Media wiernością dla bieżących nagłówków, przypisów, odnośników i profesjonalnej typografii.

Przetwarzanie wsadowe na dużą skalę: Gotenberg z poziomym skalowaniem (wiele kontenerów za równoważeniem obciążenia), IronPDF z asynchronicznym przetwarzaniem wsadowym (RenderHtmlAsPdfAsync + Parallel.ForEach), lub WeasyPrint z procesami Celery dla środowisk Python.

Wnioski

Ekosystem HTML-to-PDF w 2026 dojrzał do jasno zróżnicowanych poziomów. Narzędzia oparte na Chromium wygrały wojnę wierności renderowania — ich output pasuje do tego, co użytkownicy widzą w Chrome, a także radzą sobie z nowoczesnym JavaScript i CSS bez kompromisów. Ale ta wierność pociąga za sobą koszt zasobów, co sprawia, że lekkie alternatywy (WeasyPrint, pdfmake) są atrakcyjne dla środowisk ograniczonych.

Trzy spostrzeżenia wyróżniają się z tej analizy. Po pierwsze, przepaść między narzędziami Chromium a silnikami CSS Paged Media jest mniejsza, ale wciąż fundamentalna — jeśli twoje dokumenty wymagają bieżących nagłówków, przypisów lub układów stron świadomych, PrinceXML, PDFreactor lub WeasyPrint wciąż przewyższają każdą przeglądarkową metodę. Po drugie, bezpieczeństwo to często pobieżna myśl w większości narzędzi — tylko IronPDF i iText oferują szyfrowanie, podpisy i redakcję w jednym pakiecie, podczas gdy cały ekosystem Chromium produkuje niezabezpieczone PDFy domyślnie. Po trzecie, migracja wkhtmltopdf nie jest opcjonalna — jego podatność CVSS 9.8 SSRF aktywnie wykorzystywana, a każda organizacja, która wciąż go używa, powinna traktować wymianę jako incydent bezpieczeństwa, a nie prośbę o funkcję.