O Guia Definitivo para Ferramentas de Conversão de HTML para PDF em 2026

Como os Motores de Renderização Definem as Capacidades das Ferramentas de PDF

O fator mais importante na escolha de uma ferramenta de HTML para PDF é o seu motor de renderização. Todas as outras capacidades, suporte a CSS, execução de JavaScript, fidelidade de renderização — fluem desta decisão arquitetônica.

Ferramentas baseadas em Chromium/Blink (Puppeteer, Playwright, IronPDF, Gotenberg, PDFCrowd, PDFShift, Headless Chrome CDP, Selenium) usam o motor de navegador do Google. Carregam uma página web idêntica ao Chrome, suportam CSS3 completo (Flexbox, Grid, variáveis, queries de mídia) e executam todo o código HTML moderno. O compromisso é o consumo de recursos: ~85–200 MB de RAM por conversão sob carga concorrente, imagens Docker de 1,5–2 GB e inícios a frio de 5–15 segundos em ambientes sem servidor.

Motores CSS para PDF personalizadas (PrinceXML, PDFreactor, Antenna House, WeasyPrint, iText pdfHTML) analisam HTML e CSS usando processadores construídos especialmente. Eles se destacam no CSS Paged Media — cabeçalhos em execução, seções de rodapé, notas de rodapé e caixas de margem, recursos que os navegadores web fundamentalmente não possuem. PrinceXML foi pioneiro nessa abordagem em 2003; o presidente de sua companhia, Håkon Wium Lie, co-criou o próprio CSS. PDFreactor oferece o melhor suporte JavaScript entre os motores personalizados (ECMAScript 2025 via GraalJS). Antenna House é líder em internacionalização (80+ idiomas, 30+ scripts) e desempenho bruto via seu motor nativo em C/C++.

Criadores programáticos (PDFKit, pdfmake, jsPDF) constroem arquivos PDF a partir de código em vez de entrada HTML direta. Eles produzem saída vetorial com texto selecionável, mas exigem que os desenvolvedores definam o layout de forma programática — sem análise de HTML/CSS. Ferramentas de captura de tela do lado do cliente (html2pdf.js) capturam DOM renderizado no navegador como imagens rasterizadas, produzindo documentos não-selecionáveis e não-buscáveis com limitações significativas de tamanho e qualidade de página.

Matriz de Comparação Completa Ferramenta por Ferramenta

A tabela a seguir destila os atributos mais relevantes para decisão para todas as 23 ferramentas. Análise detalhada de cada uma segue nas seções subsequentes.

IronPDF: Converta Arquivos HTML para PDF Com Facilidade Com Esta Biblioteca que Se Destaca

IronPDF merece uma análise extensa porque ocupa uma posição única: um motor de renderização baseado em Chromium envolvido em uma biblioteca nativa .NET com uma extraordinariamente ampla caixa de ferramentas para PDF. Onde Puppeteer exige que os desenvolvedores instalem e anexem bibliotecas separadas para criptografia, assinaturas digitais ou manipulação de formulários, IronPDF reúne tudo isso em um único pacote NuGet.

A arquitetura de renderização incorpora um motor Chrome customizado e otimizado que permanece ativo para renderizações subsequentes, eliminando a geração de processos por PDF que torna o Puppeteer bruto caro em escala. IronPDF afirma ter um desempenho 5–20× mais rápido do que soluções baseadas em web-driver para cenários de alta carga. Revisões do G2 confirmam "relatórios de 100+ páginas com precisão pixel-perfect" e completa fidelidade CSS.

A ergonomia da API é genuinamente mínima para qualquer arquivo HTML. O padrão central são duas linhas de 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")

Configuração escala de maneira limpa: RenderingOptions expõe troca de tipo de mídia CSS, estratégias de espera do JavaScript, injeção de CSS personalizada e controle de viewport responsivo via PaperFit. A amplitude da ferramenta é o principal diferencial. IronPDF suporta mesclagem, divisão, copiar/excluir arquivos, criptografia AES-256, assinaturas digitais X.509, redação permanente, criação de marca d'água baseada em HTML, orientação de página em conformidade com PDF/A, saída acessível PDF/UA e criação de AcroForm a partir de elementos

Ferramentas de Automação Web Compartilham Forças e Limites do Chromium

Puppeteer, Playwright, Headless Chrome CDP, Selenium e Gotenberg, todos, em última análise, invocam o comando Page.printToPDF do CDP do Chromium. Suas diferenças residem no nível de abstração, suporte a linguagens e ergonomia operacional.

Puppeteer (Google, Apache 2.0) permanece a opção mais madura for Node.js com 31,1k estrelas no GitHub. Sua API page.pdf() expõe formato de papel, escala (0,1–2×), margens, modelos de cabeçalho/rodapé em HTML com classes de injeção (pageNumber, totalPages, date), impressão de fundo, intervalos de páginas e geração experimental de estrutura de documento. Um estudo de caso da Carriyo documentou 10.000 PDFs/dia no AWS Lambda. O método page.createPDFStream() lida com documentos grandes sem falhas de memória. Puppeteer levou em média 7,84 segundos para 10 PDFs em benchmarks, aproximadamente 3× mais rápido que o wkhtmltopdf para o mesmo conteúdo.

Playwright (Microsoft, Apache 2.0) oferece capacidades de PDF quase idênticas, mas adiciona suporte oficial a múltiplas linguagens (JavaScript, Python, Java, .NET) e espera automática integrada que reduz a instabilidade em comparação com o waitForSelector manual do Puppeteer. A versão 1.42+ adicionou geração de estrutura de PDF/marcadores a partir de estrutura de cabeçalho. A geração de PDF é somente Chromium, não funciona com os navegadores Firefox ou WebKit do Playwright. Benchmarks mostram Playwright em média 4.513s versus 4.784s do Puppeteer para fluxos de trabalho pesados de navegação.

Gotenberg envolve Chromium (e LibreOffice para documentos do Office) em uma API HTTP Docker baseada em Go sob licença MIT. É a arquitetura de referência para PDF como um microsserviço: sem estado, agnóstico de linguagem via multipart/form-data e disponível como imagens otimizadas para Cloud Run e AWS Lambda. Única adiciona criptação PDF (AES-256 via QPDF), conformidade com PDF/A (1a, 2b, 3b), operações de mesclagem/divisão e edição de metadados de PDF, capacidades que nenhuma outra ferramenta baseada em Chromium fornece nativamente. A simultaneidade é limitada a 6 conversões Chromium paralelas por instância (configurável), com escalabilidade horizontal por meio de contêineres adicionais.

Headless Chrome CDP é a opção de nível mais baixo, sem sobrecarga de biblioteca, apenas binário do Chrome e um cliente CDP em qualquer linguagem (Go, Python, Ruby, Elixir). O modo CLI (chrome --headless --print-to-pdf) está sendo descontinuado em favor da API CDP. O compromisso é gerenciar o ciclo de vida do processo Chrome, processos zumbis e implementar suas próprias estratégias de espera manualmente.

Selenium + PDF de navegador é a opção mais fraca para geração de PDF. Sua API PrintsPage padrão tem opções limitadas; modelos completos de cabeçalho/rodapé requerem a ponte CDP (driver.execute_cdp_cmd("Page.printToPDF", {...})), que só funciona com Chromium e é em si temporário (em transição para WebDriver BiDi). A documentação do pacote selenium-print adverte explicitamente: "se a sua prioridade é desempenho, esta não é a biblioteca para você."

Nenhuma dessas ferramentas produz formulários PDF preenchíveis — o print-to-PDF do Chromium achata todos os elementos do formulário. Nenhuma delas suporta nativamente criptografia de PDF, assinaturas digitais ou redação. Para esses recursos, é necessário pós-processamento com bibliotecas externas (pdf-lib, QPDF, iText) — ou use o Gotenberg, que integra essas ferramentas.

Motores CSS Comerciais Excel em Publicação de Documentos PDF Paginados

PrinceXML, PDFreactor e Antenna House comandam preços premium porque implementam especificações W3C CSS Paged Media que navegadores web simplesmente não possuem. Eles gerenciam configurações de tamanho de página, caixas de margem esquerda, notas de rodapé, páginas nomeadas e geração automática de índice.

PrinceXML ($3.800/servidor uma vez, $495/desktop) é o padrão dourado. Seu motor personalizado, escrito em Mercury, produziu a saída CSS Paged Media com a mais alta fidelidade desde 2003. Prince suporta Flexbox (desde a v12, 2018) e CSS Grid (desde v16, ~2024, com fragmentação entre páginas ainda em amadurecimento). JavaScript é limitado a ES5 apenas — sem funções de seta, Promises ou async/await. Suporta PDF/A-1a/1b/3a/3b, PDF/UA-1, PDF/X-1a/3/4, criptografia RC4 (40/128-bit), mas não suporta assinaturas digitais (uma omissão de longa data). Uma licença gratuita não comercial com marca d'água está disponível para desenvolvimento.

PDFreactor ($1.908/ano Pro assinatura) é o mais avançado tecnicamente. Sua integração com GraalJS fornece suporte a ECMAScript 2025 (requer Java 20+), tornando-o o único motor CSS personalizado com JavaScript moderno completo. Suporta Regiões CSS, Formas CSS, grades de base e o conjunto mais amplo de variantes PDF/A (1a até 3u). Criticamente, inclui assinatura digital incorporada — algo que Prince não possui. A implantação é via JAR Java, serviço web incorporado Jetty ou contêiner Docker. Clientes corporativos incluem Dell Technologies e Deutsche Post (500.000+ funcionários).

Antenna House Formatter ($5.000/servidor perpétuo para XSL-FO, $1.250/autônomo para CSS) é único como um motor duplo de XSL-FO e CSS. Sua implementação nativa em C/C++ oferece o desempenho bruto mais rápido com a menor pegada de memória. Suporta 80+ idiomas e 30+ scripts — inigualável em internacionalização. No entanto, não possui suporte a JavaScript de forma alguma, e CSS Grid não é suportado. Seu público principal são fluxos de trabalho de publicação centrados em XML (DITA, DocBook), onde XSL-FO oferece mais controle granular do que CSS.

Ferramentas do Ecossistema Java Variam de Corporativas a Leves

iText pdfHTML é a opção Java mais capaz, suportando Flexbox (compreensivo desde 2025), CSS Grid (desde 2024), cabeçalhos/rodapés CSS Paged Media e conversão de HTML para AcroForm. Sua restrição crítica é o licenciamento: AGPL v3 exige open sourcing de todo o seu aplicativo se você distribuir ou oferecer como um serviço de rede. Licenças comerciais variam de ~$10.000/ano (pequenas implantações) para $210.000+/ano (enterprise), com uma média da indústria de ~$45.000/ano por dados Vendr. iText não executa nenhum JavaScript, é apenas um analisador estático de HTML/CSS.

OpenHTMLtoPDF e Flying Saucer são as alternativas licenciadas LGPL, utilizáveis livremente em software proprietário. Ambos são limitados ao CSS 2.1 — sem Flexbox, sem Grid — e não executam JavaScript. O repositório original do OpenHTMLtoPDF (danfickle/openhtmltopdf, 2.1k estrelas) foi abandonado em ~2022; um fork comunitário ativo no io.github.openhtmltopdf (Maven Central, v1.1.31, setembro de 2025) foi migrado para o PDFBox 3.x. Flying Saucer (2.2k estrelas) permanece em manutenção ativa por @asolntsev (v10.0.6, dezembro de 2025), mas agora requer Java 21+ para a última versão. Ambas as ferramentas requerem entrada XHTML bem-formada, elas não podem processar "wild" HTML arbitrário.

⚠ Nota de qualidade de origem: as alegações de suporte ao CSS para OpenHTMLtoPDF e Flying Saucer vêm principalmente de READMEs do projeto e relatórios comunitários. Não existem matrizes de suporte CSS abrangentes ou validação de terceiros para nenhuma das ferramentas. As alegações de desempenho são auto-relatadas sem benchmarks independentes.

Ferramentas do Lado do Cliente JavaScript Servem Muito Bem Casos de Uso Restritos

pdfmake (12,2k estrelas, 1,1M+ downloads semanais no npm) é a opção mais forte do lado do cliente para documentos estruturados. Usa uma definição de documento declarativa em JSON — não HTML — com paginação automática integrada, repetição de cabeçalho de tabela em várias páginas, cabeçalhos/rodapés dinâmicos com contagens de páginas e saída vetorial (texto pesquisável, selecionável). Suporta PDF/A (beta) e criptografia. A curva de aprendizado é sua sintaxe declarativa, que exige reexpressar conteúdo que já pode existir como HTML.

PDFKit (10,5k estrelas, 1,2M+ downloads semanais) fornece controle imperativo de baixo nível, uma API semelhante a canvas para posicionamento preciso. Sua API de streaming torna-o eficiente em memória para documentos grandes do lado do servidor. Suporta criação de AcroForm, acessibilidade PDF/UA e criptografia RC4/AES. No entanto, não possui análise de HTML/CSS e nenhum suporte a tabelas integrado (requerendo plugins como pdfkit-table).

jsPDF (31,1k estrelas, ~2,5M downloads semanais) é o mais popular por download. Seu método .html() usa html2canvas para capturar DOM como imagens rasterizadas, produzindo PDFs não selecionáveis, não pesquisáveis com grandes tamanhos de arquivo. Seu plugin AcroForm pode criar campos de formulário preenchíveis de forma programática, mas não a partir de elementos de formulário HTML. O limite de tamanho do canvas (~16.384px de altura) causa páginas em branco para documentos longos.

html2pdf.js (4,8k estrelas) envolve jsPDF + html2canvas na API mais simples possível: html2pdf(elemento). A saída são inteiramente imagens rasterizadas. O limite de tamanho do canvas é sua falha mais crítica — documentos que excedem ~16.384px são renderizados como páginas completamente em branco (issue #19 do GitHub). Possui 462 issues abertos, roda apenas em navegadores (sem Node.js) e produz saída não-acessível.

APIs na Nuvem trocam controle por simplicidade operacional

DocRaptor ($15–$1.000+/mês) é a única API que usa o PrinceXML, dando-lhe suporte inigualável a CSS Paged Media, conversão automática de HTML para PDF preenchíveis e saída acessível WCAG/Section 508. Oferece um SLA de 99,99% de uptime, conformidade SOC 2 e HIPAA, 30 documentos simultâneos independentemente do plano e documentos de teste gratuitos e ilimitados com marca d'água. O compromisso é a limitação do JavaScript ES5 do Prince e a implantação somente na nuvem.

Nutrient Document Engine (anteriormente PSPDFKit, rebatizado em 2024 após €100M da Insight Partners) é a plataforma mais abrangente — não apenas HTML para PDF, mas um SDK de processamento de documentos completo abrangendo Web, iOS, Android, .NET e mais. Oferece certificação SOC 2 Tipo II, conformidade WCAG 2.2 AA, redação com inteligência artificial e assinaturas digitais criptográficas. Implantação Docker auto-hospedada está disponível. Os preços da API na nuvem DWS começam em $67/mês (1.000 créditos, com HTML para PDF custando 0,5 crédito cada). O licenciamento do SDK é opaco, exigindo contato de vendas, com contratos corporativos relatadamente alcançando compromissos anuais significativos.

PDFShift se destaca pela simplicidade: integração em 3 linhas, um generoso nível gratuito (50 conversões/mês), 50 conversões paralelas em todos os planos, manuseio de dados com prioridade na privacidade (sem armazenamento de documentos) e disponibilidade de HIPAA BAA. Os preços variam de $9–$99+/mês. Falta suporte a CSS Paged Media, formulários preenchíveis e PDF acessível.

PDFCrowd usa Chromium com precificação baseada em créditos ligada ao tamanho do arquivo de saída (1 crédito = 0,5 MB de saída), tornando os custos imprevisíveis para documentos de tamanho variável. Os limites de taxa variam de 15–360 conversões/minuto por plano. Falta suporte a PDF acessível/tagueado e não tem SLA de uptime público.

APITemplate.io ($19–$179/mês para planos somente PDF) foca em geração orientada por modelos com um editor WYSIWYG, integrações Zapier/Make.com, e endpoints de API regionais (EUA, EU, Singapura, Austrália). É otimizado para tipos de documentos repetitivos (faturas, certificados, relatórios) em vez de conversão de HTML arbitrário.

wkhtmltopdf é um risco de segurança crítico que requer substituição

wkhtmltopdf foi arquivado no GitHub em janeiro de 2023 e marcado como não mais mantido pelos administradores em julho de 2024. Sua última versão (0.12.6, junho de 2020) usa um motor Qt WebKit de aproximadamente 2012 com nenhum patch de segurança desde o arquivamento. A vulnerabilidade mais grave, CVE-2022-35583 (CVSS 9.8 Crítico), permite a falsificação de solicitação do lado do servidor: um invasor injetando um iframe no HTML fornecido pelo usuário pode acessar recursos de rede interna, incluindo metadados de instância do AWS EC2 em 169.254.169.254, potencialmente levando à tomada completa da infraestrutura. CVE-2020-21365 (CVSS 7,5) permite travessia de diretórios para leitura de arquivos locais.

A própria página de status do mantenedor do wkhtmltopdf adverte: "Não use wkhtmltopdf com qualquer HTML não confiável." CiviCRM emitiu CIVI-PSA-2024-01 recomendando remoção imediata. A Pantheon o removeu do PHP Runtime Gen 2 em 2025. Apesar disso, wkhtmltopdf permanece embutido em bibliotecas de contorno em todo grande ecossistema de linguagem (Python's pdfkit, Ruby's wicked_pdf, PHP's KnpSnappy, .NET's DinkToPdf).

Caminhos de migração: Puppeteer/Playwright para execução completa de JavaScript (equivalente funcional mais próximo), WeasyPrint para pilhas Python não precisando de JS, Gotenberg para arquiteturas de microsserviço, ou DocRaptor/PrinceXML para necessidades de CSS Paged Media.

Benchmarks de desempenho revelam claros compromissos de recursos

Benchmarks independentes de Kyotu Technology e hardkoded.com fornecem comparações quantitativas:

As imagens Docker do WeasyPrint são dramaticamente menores em 200–400 MB, e o motor de renderização não possui dependência de Chromium. No entanto, sabe-se que o WeasyPrint é lento para documentos complexos — um PDF de 52 páginas levou ~100 segundos em um benchmark, e grandes tabelas (5.000+ linhas) podem consumir 1,4+ GB de RAM.

Para sem servidor, a métrica crítica é o tempo de inicialização a frio. Funções Lambda baseadas em Chromium experimentam inicializações a frio de 5 a 15 segundos devido à descompressão binária. Usando @sparticuz/chromium-min (~50 MB comprimido) com Puppeteer-core cabe dentro do limite de 250 MB da Lambda e reduz o tamanho do pacote de ~41 MB para ~769 KB. A simultaneidade provisionada reduz a inicialização a frio para ~400 ms, mas adiciona custo. A memória da Lambda deve ser no mínimo 1.024 MB, idealmente 1.600 MB para geração de PDF Chromium confiável.

As capacidades de segurança variam dramaticamente entre as ferramentas

Apenas iText e IronPDF proporcionam o trio completo de segurança de criptografia, assinaturas digitais e redação. A iText Suite 9.5 está adicionando algoritmos de assinatura resilientes para pós-quantum para garantir o futuro. Entre as APIs de nuvem, DocRaptor (SOC 2, HIPAA) e Nutrient (SOC 2 Tipo II, HIPAA, WCAG 2.2) lideram em certificações de conformidade.

Pegadinhas de implantação que toda equipe deve antecipar

As fontes são a causa nº 1 das diferenças de renderização entre desenvolvimento e produção. Imagens Docker mínimas carecem completamente de fontes, produzindo caracteres tofu (□) para texto não ASCII. A solução é instalar pacotes abrangentes de fontes — a família de fontes Noto cobre praticamente todos os sistemas de escrita. Para suporte a CJK, fonts-noto-cjk é essencial. Fontes personalizadas devem ser copiadas para /usr/local/share/fonts/ com fc-cache -f -v rodando em seguida.

O sandboxing do Chromium no Docker é o problema nº 2 de implantação. O Chromium requer namespaces do kernel do Linux que contêineres Docker frequentemente não possuem, produzindo erros de execução como root sem --no-sandbox não é suportado. A solução correta em termos de segurança é criar um usuário não-root (useradd -r pptruser); a solução expedita é --no-sandbox, que reduz a segurança e só deve ser usada para conteúdo confiável.

Acúmulo de memória é o assassino silencioso em processos de Chromium de longa execução. A memória aumenta com cada conversão, eventualmente causando travamentos OOM. Mitigações críticas incluem: aumentar a memória compartilhada do Docker (--shm-size=512M, pois o padrão de 64 MB causa travamentos), usar --disable-dev-shm-usage, reiniciar instâncias do navegador após N conversões (o Gotenberg faz isso automaticamente após 100), e usar dumb-init ou Docker --init para coletar processos zumbis. Uma única tabela HTML com 50.000 linhas pode consumir 10+ GB de RAM no Chromium.

Temporização de JavaScript causa PDFs incompletos quando o conteúdo dinâmico não terminou de carregar. Use waitUntil: 'networkidle0' (espera por zero conexões de rede por 500 ms) ou page.waitForSelector('.data-loaded') para prontidão explícita de elementos. O Gotenberg atenua isso ao esperar por eventos DomContent, Load, NetworkIdle e LoadingFinished por padrão, adicionando cerca de 2 segundos de latência base, mas garantindo a completude.

Qual ferramenta se adequa a qual caso de uso

Faturas e extratos: WeasyPrint (pilhas Python — leve, excelente CSS Paged Media, sem overhead do Chromium), Gotenberg (microserviço agnóstico de linguagem) ou pdfmake (documentos estruturados no lado do cliente). Para .NET, IronPDF oferece a API mais ergonômica.

Relatórios e painéis com gráficos: Puppeteer ou Playwright — apenas motores de navegador completos podem executar nativamente D3.js, Chart.js ou Plotly. O WeasyPrint não pode renderizar gráficos gerados por JavaScript. O mecanismo Chromium do IronPDF lida com isso dentro de aplicativos .NET sem iniciar processos externos.

Renderização de SPA para PDF: Puppeteer ou Playwright são as únicas opções realistas. Os frameworks modernos (React, Angular, Vue) requerem execução completa de navegador. A configuração waitUntil é crítica para garantir que todo o conteúdo assíncrono tenha carregado.

Conformidade e segurança (PDF/A, assinatura digital, criptografia): iText (mais completo mas caro), IronPDF (.NET, recursos de segurança amplos) ou PDFreactor (Java, assinatura embutida). Ferramentas baseadas em Chromium requerem pós-processamento externo para quaisquer recursos de segurança.

Sem servidor e contêineres: Gotenberg (construído para contêineres, licença MIT, imagens Cloud Run/Lambda) ou Puppeteer-core + @sparticuz/chromium-min para AWS Lambda (50 MB compactados, cabe dentro dos limites).

Publicação com qualidade de impressão: PrinceXML ou DocRaptor (API) — nada mais se aproxima de sua fidelidade em CSS Paged Media para cabeçalhos corridos, notas de rodapé, referências cruzadas e tipografia profissional.

Processamento em lote em escala: Gotenberg com escalonamento horizontal (múltiplos contêineres atrás de um balanceador de carga), IronPDF com processamento em lote assíncrono (RenderHtmlAsPdfAsync + Parallel.ForEach) ou WeasyPrint com Celery workers para ambientes Python.

Conclusão

O ecossistema HTML-to-PDF em 2026 amadureceu em níveis claramente diferenciados. Ferramentas baseadas em Chromium venceram a guerra de fidelidade de renderização — sua saída coincide com o que os usuários veem no Chrome, e eles lidam com JavaScript e CSS modernos sem comprometer. Mas essa fidelidade vem a um custo de recursos que torna alternativas leves (WeasyPrint, pdfmake) atraentes para ambientes restritos.

Três insights se destacam desta análise. Primeiro, a lacuna entre ferramentas Chromium e motores CSS Paged Media está se estreitando mas continua fundamental — se seus documentos precisam de cabeçalhos corridos, notas de rodapé ou layouts conscientes de páginas, PrinceXML, PDFreactor ou WeasyPrint ainda superam qualquer abordagem baseada em navegador. Segundo, a segurança é um pensamento tardio na maioria das ferramentas — apenas IronPDF e iText fornecem criptografia, assinaturas, e redação em um único pacote, enquanto todo o ecossistema Chromium produz PDFs desprotegidos por padrão. Terceiro, a migração do wkhtmltopdf não é opcional — sua vulnerabilidade CVSS 9.8 SSRF é ativamente explorável, e toda organização ainda a usando deve tratar a substituição como um incidente de segurança, não como um pedido de recurso.