La guía definitiva de herramientas de conversión de HTML a PDF en 2026

Cómo los motores de renderizado definen las capacidades de las herramientas PDF

El factor más importante al elegir una herramienta de HTML a PDF es su motor de renderizado. Todas las demás capacidades, soporte de CSS, ejecución de JavaScript, fidelidad de renderización, dependen de esta decisión arquitectónica.

Las herramientas basadas en Chromium/Blink (Puppeteer, Playwright, IronPDF, Gotenberg, PDFCrowd, PDFShift, Headless Chrome CDP, Selenium) usan el motor del navegador de Google. Cargan una página web idénticamente a Chrome, soportan CSS3 completo (Flexbox, Grid, variables, consultas de medios) y ejecutan todo el código HTML moderno. La contrapartida es el consumo de recursos: ~85–200 MB de RAM por conversión bajo carga concurrente, imágenes Docker de 1.5 a 2 GB, y arranques en frío de 5 a 15 segundos en entornos sin servidor.

Motores CSS-a-PDF personalizados (PrinceXML, PDFreactor, Antenna House, WeasyPrint, iText pdfHTML) analizan HTML y CSS usando procesadores de renderizado a medida. Sobresalen en medios paginados de CSS, encabezados continuos, secciones de pie de página, notas al pie, y cajas de margen, características que los navegadores web carecen fundamentalmente. PrinceXML fue pionero en este enfoque en 2003; su presidente Håkon Wium Lie co-creó CSS. PDFreactor ofrece el mejor soporte de JavaScript entre los motores personalizados (ECMAScript 2025 a través de GraalJS). Antenna House lidera en internacionalización (80+ idiomas, 30+ script) y rendimiento bruto a través de su motor nativo C/C++.

Los constructores programáticos (PDFKit, pdfmake, jsPDF) construyen archivos PDF a partir de código en lugar de entrada directa de HTML. Producen salida vectorial con texto seleccionable pero requieren que los desarrolladores definan el diseño programáticamente, sin análisis de HTML/CSS. Las herramientas de captura del lado del cliente (html2pdf.js) capturan el DOM renderizado por el navegador como imágenes rasterizadas, produciendo documentos no seleccionables ni buscables con limitaciones significativas de tamaño y calidad de página.

Matriz completa de comparación herramienta por herramienta

La siguiente tabla destila los atributos más relevantes para la decisión para las 23 herramientas. El análisis detallado de cada uno sigue en secciones posteriores.

IronPDF: Convierta archivos HTML a PDF con facilidad con esta extraordinaria biblioteca

IronPDF merece un análisis extenso porque ocupa una posición única: un motor de renderizado basado en Chromium envuelto en una biblioteca nativa .NET con un conjunto de herramientas PDF inusualmente amplio. Donde Puppeteer requiere que los desarrolladores instalen y adjunten bibliotecas separadas para cifrado, firmas digitales o manipulación de formularios, IronPDF agrupa todo esto en un solo paquete NuGet.

La arquitectura de renderizado integra un motor Chrome optimizado a medida que se mantiene caliente para renderizados subsecuentes, eliminando el lanzamiento de procesos por cada PDF que hace que Puppeteer crudo sea costoso a gran escala. IronPDF afirma un rendimiento entre 5 y 20 veces más rápido que las soluciones basadas en controlador web para escenarios de alta carga. Las revisiones de G2 confirman "informes de 100+ páginas con precisión de píxeles perfecta" y fidelidad completa de CSS.

La ergonomía de la API es realmente mínima para cualquier archivo HTML. El patrón central son dos líneas 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")

La configuración escala limpiamente: RenderingOptions expone el cambio de tipo de medio CSS, estrategias de espera de JavaScript, inyección de CSS personalizada y control de ventana de visualización receptivo a través de PaperFit. La amplitud de las herramientas es el principal diferenciador. IronPDF admite combinar, dividir, copiar/eliminar archivos, cifrado AES-256, firmas digitales X.509, redacción permanente, marca de agua basada en HTML, orientación de páginas, compatibilidad con PDF/A, salida accesible PDF/UA y creación de AcroForm desde elementos de

Las herramientas de automatización web comparten fortalezas y límites de Chromium

Puppeteer, Playwright, Headless Chrome CDP, Selenium y Gotenberg invocan en última instancia el comando CDP Page.printToPDF de Chromium. Sus diferencias radican en el nivel de abstracción, soporte de lenguajes y ergonomía operativa.

Puppeteer (Google, Apache 2.0) sigue siendo la opción de Node.js más madura con 31.1k estrellas en GitHub. Su API página.pdf() expone el formato de papel, escala (0.1–2×), márgenes, plantillas de HTML de encabezado/pie de página con clases de inyección (númeroDePágina, totalDePáginas, fecha), impresión de fondo, rangos de páginas y generación experimental de esbozos de documentos. Un estudio de caso de Carriyo documentó 10,000 PDFs/día en AWS Lambda. El método página.createPDFStream() maneja documentos grandes sin choques de memoria. Puppeteer promedió 7.84 segundos para 10 PDFs en benchmarks, aproximadamente 3 veces más rápido que wkhtmltopdf para el mismo contenido.

Playwright (Microsoft, Apache 2.0) ofrece capacidades de PDF casi idénticas pero añade soporte multilingüe oficial (JavaScript, Python, Java, .NET) y espera automática incorporada que reduce la inestabilidad en comparación con el waitForSelector manual de Puppeteer. La versión 1.42+ agregó la generación de esquema/marcadores de PDF desde la estructura de encabezados. La generación de PDF es sólo en Chromium, no funciona con los navegadores Firefox o WebKit de Playwright. Las pruebas muestran que Playwright promedia 4.513s frente a 4.784s de Puppeteer para flujos de trabajo con mucha navegación.

Gotenberg envuelve Chromium (y LibreOffice para documentos de Office) en una API HTTP de Docker basada en Go bajo licencia MIT. Es la arquitectura de referencia para PDF como microservicio: sin estado, independiente del lenguaje vía multipart/form-data, y disponible como imágenes optimizadas para Cloud Run y AWS Lambda. Añade de forma exclusiva cifrado PDF (AES-256 vía QPDF), cumplimiento PDF/A (1a, 2b, 3b), operaciones de combinación/división y edición de metadatos de PDF, capacidades que ninguna otra herramienta basada en Chromium ofrece de forma nativa. La concurrencia está limitada a 6 conversiones de Chromium paralelas por instancia (configurable), con escalado horizontal a través de contenedores adicionales.

Headless Chrome CDP es la opción de menor nivel, sin sobrecarga de biblioteca, solo el binario de Chrome y un cliente CDP en cualquier lenguaje (Go, Python, Ruby, Elixir). El modo CLI (chrome --headless --print-to-pdf) está siendo desaprobado a favor de la API CDP. La contrapartida es gestionar el ciclo de vida del proceso de Chrome, los procesos zombis e implementar sus propias estrategias de espera manualmente.

Selenium + PDF de navegador es la opción más débil para la generación de PDF. Su API estándar PrintsPage tiene opciones limitadas; las plantillas de encabezado/pie de página completas requieren el puente CDP (driver.execute_cdp_cmd("Page.printToPDF", {...})), que solo funciona con Chromium y es temporal (pasando a WebDriver BiDi). La documentación del paquete selenium-print advierte explícitamente: "si su prioridad es el rendimiento, esta no es la biblioteca para usted".

Ninguna de estas herramientas produce formularios PDF rellenables — la impresión a PDF de Chromium aplana todos los elementos de formulario. Ninguna admite cifrado PDF, firmas digitales o redacción de forma nativa. Para estas características, se requiere post-procesamiento con bibliotecas externas (pdf-lib, QPDF, iText), o use Gotenberg, que integra estas herramientas.

Los motores CSS comerciales sobresalen en la publicación de documentos PDF paginados

PrinceXML, PDFreactor y Antenna House tienen precios premium porque implementan especificaciones de medios paginados CSS de W3C que los navegadores web simplemente no tienen. Manejan configuraciones de tamaño de página, cajas de margen izquierdo, notas al pie, páginas nombradas y generación automática de tablas de contenido.

PrinceXML ($3,800/servidor único, $495/escritorio) es el estándar de oro. Su motor personalizado, escrito en Mercury, ha producido la salida CSS de medios paginados de mayor fidelidad desde 2003. Prince admite Flexbox (desde v12, 2018) y CSS Grid (desde v16, ~2024, con la fragmentación de página cruzada aún en maduración). JavaScript está limitado a solo ES5 — sin funciones de flecha, Promises, o async/await. Admite PDF/A-1a/1b/3a/3b, PDF/UA-1, PDF/X-1a/3/4, cifrado RC4 (40/128 bits), pero no admite firmas digitales (una omisión de larga data). Una licencia gratuita no comercial con marca de agua está disponible para desarrollo.

PDFreactor ($1,908/año suscripción Pro) es el más avanzado técnicamente. Su integración GraalJS proporciona soporte para ECMAScript 2025 (requiere Java 20+), lo que lo convierte en el único motor CSS personalizado con JavaScript moderno completo. Admite CSS Regions, CSS Shapes, cuadrículas de base y el conjunto más amplio de variantes de PDF/A (1a hasta 3u). De manera crítica, incluye firma digital incorporada, algo que Prince carece. El despliegue es a través de JAR de Java, servicio web Jetty embebido o contenedor Docker. Los clientes empresariales incluyen Dell Technologies y Deutsche Post (500,000+ empleados).

Antenna House Formatter ($5,000/servidor perpetuo para XSL-FO, $1,250/independiente para CSS) es único como un motor dual de XSL-FO y CSS. Su implementación nativa en C/C++ ofrece el rendimiento bruto más rápido con el menor uso de memoria. Admite 80+ idiomas y 30+ scripts — inigualable para la internacionalización. Sin embargo, no tiene soporte for JavaScript en absoluto, y CSS Grid no está soportado. Su público principal son las flujos de trabajo de publicación centrada en XML (DITA, DocBook) donde XSL-FO proporciona un control más granular que CSS.

Las herramientas del ecosistema de Java varían desde empresariales hasta ligeras

iText pdfHTML es la opción más capaz de Java, soportando Flexbox (completo desde 2025), CSS Grid (desde 2024), encabezados/pies de medios paginados CSS y conversión de HTML a AcroForm. Su restricción crítica es la licencia: AGPL v3 requiere liberar el código fuente de toda su aplicación si la distribuye o la ofrece como un servicio de red. Las licencias comerciales van desde ~$10,000/año (implementaciones pequeñas) hasta $210,000+/año (empresarial), con un promedio industrial de ~$45,000/año según datos de Vendr. iText no ejecuta JavaScript, es solo un analizador estático de HTML/CSS.

OpenHTMLtoPDF y Flying Saucer son las alternativas con licencia LGPL, libres de uso en software propietario. Ambos están limitados a CSS 2.1 — sin Flexbox, sin Grid — y no ejecutan JavaScript. El repositorio original de OpenHTMLtoPDF (danfickle/openhtmltopdf, 2.1k estrellas) fue abandonado en ~2022; un fork comunitario activo en io.github.openhtmltopdf (Maven Central, v1.1.31, septiembre 2025) ha migrado a PDFBox 3.x. Flying Saucer (2.2k estrellas) permanece activamente mantenido por @asolntsev (v10.0.6, diciembre 2025) pero ahora requiere Java 21+ para la última versión. Ambas herramientas requieren entrada XHTML bien formada, no pueden procesar HTML "salvaje" arbitrario.

⚠ Nota sobre la calidad de la fuente: las afirmaciones sobre el soporte de CSS para OpenHTMLtoPDF y Flying Saucer provienen principalmente de los READMEs del proyecto e informes comunitarios. No existen matrices de soporte CSS completas o validación de terceros para ninguna de las herramientas. Las afirmaciones de rendimiento son auto-reportadas sin benchmarks independientes.

Las herramientas JavaScript del lado del cliente sirven bien a casos de uso estrechos

pdfmake (12.2k estrellas, 1.1M+ descargas npm semanales) es la opción más fuerte del lado del cliente para documentos estructurados. Utiliza una definición de documento JSON declarativa, no HTML, con paginación automática incorporada, repetición de encabezados de tabla en páginas, encabezados/pies dinámicos con conteo de páginas y salida vectorial (texto buscable, seleccionable). Admite PDF/A (beta) y cifrado. La curva de aprendizaje es su sintaxis declarativa, que requiere reexpresar contenido que puede ya existir como HTML.

PDFKit (10.5k estrellas, 1.2M+ descargas semanales) proporciona control imperativo de bajo nivel, una API similar a un lienzo para posicionamiento preciso. Su API de transmisión la hace eficiente en memoria para documentos grandes del lado del servidor. Admite creación de AcroForm, accesibilidad PDF/UA, y cifrado RC4/AES. Sin embargo, no tiene análisis de HTML/CSS ni soporte de tabla incorporado (requiriendo plugins como pdfkit-table).

jsPDF (31.1k estrellas, ~2.5M descargas semanales) es el más popular por descargas. Su método .html() usa html2canvas para capturar el DOM como imágenes rasterizadas, produciendo PDFs no seleccionables ni buscables con tamaños de archivo grandes. Su plugin AcroForm puede crear campos de formulario rellenables por programación, pero no desde elementos de formulario HTML. El límite de tamaño del lienzo (~16,384px de altura) causa páginas en blanco para documentos largos.

html2pdf.js (4.8k estrellas) envuelve jsPDF + html2canvas en la API más simple posible: html2pdf(element). La salida son completamente imágenes rasterizadas. El límite de tamaño del lienzo es su defecto más crítico — los documentos que superen ~16,384px se renderizan como páginas completamente en blanco (issues de GitHub #19). Tiene 462 issues abiertos, solo se ejecuta en navegadores (no Node.js), y produce salida no accesible.

Las APIs en la nube intercambian control por simplicidad operativa

DocRaptor ($15–$1,000+/mes) es la única API que usa PrinceXML, dándole soporte inigualable para medios paginados CSS, conversión automática de HTML a PDF rellenables y salida accesible WCAG/Sección 508. Ofrece un SLA de disponibilidad del 99.99%, cumplimiento SOC 2 e HIPAA, 30 documentos concurrentes independientemente del plan, y pruebas de documentos con marca de agua ilimitadas gratuitas. La contrapartida es la limitación JavaScript solo ES5 de Prince y el despliegue solo en la nube.

Motor de documentos Nutrient (anteriormente PSPDFKit, renombrado en 2024 después de receiving €100M de Insight Partners) es la plataforma más comprensiva — no solo HTML-a-PDF sino un SDK completo de procesamiento de documentos que abarca Web, iOS, Android, .NET, y más. Ofrece certificación SOC 2 Tipo II, cumplimiento con WCAG 2.2 AA, redacción impulsada por IA y firmas digitales criptográficas. El despliegue autogestionado en Docker está disponible. La tarifa de precios del API en la nube DWS comienza en $67/mes (1,000 créditos, con HTML-a-PDF costando 0.5 créditos por cada uno). La licencia del SDK es opaca, requiriendo contacto con ventas, con contratos empresariales que supuestamente alcanzan compromisos anuales significativos.

PDFShift se destaca por su simplicidad: integración de 3 líneas, un nivel gratuito generoso (50 conversiones/mes), 50 conversiones paralelas en todos los planes, manejo de datos privado primero (sin almacenamiento de documentos), y disponibilidad de HIPAA BAA. Los precios oscilan entre $9–$99+/mes. Carece de medios paginados CSS, formularios rellenables y soporte PDF accesible.

PDFCrowd usa Chromium con precios basados en créditos ligados al tamaño de archivo de salida (1 crédito = 0.5 MB de salida), haciendo los costos impredecibles para documentos de tamaño variable. Los límites de velocidad oscilan entre 15–360 conversiones/minuto por plan. Carece de soporte PDF accesible/etiquetado y no tiene un SLA público de tiempo de actividad.

APITemplate.io ($19–$179/mes para planes solo de PDF) se centra en la generación impulsada por plantillas con un editor WYSIWYG, integraciones Zapier/Make.com y puntos finales de API regionales (EE. UU., UE, Singapur, Australia). Está optimizado para tipos de documentos repetitivos (facturas, certificados, informes) en lugar de conversión de HTML arbitrario.

wkhtmltopdf es un riesgo crítico de seguridad que requiere reemplazo

wkhtmltopdf fue archivado en GitHub en enero de 2023 y marcado como no mantenido por administradores en julio de 2024. Su última versión (0.12.6, junio de 2020) usa un motor Qt WebKit de aproximadamente 2012 con sin parches de seguridad desde el archivado. La vulnerabilidad más severa, CVE-2022-35583 (CVSS 9.8 Crítico), permite falsificación de solicitudes del lado servidor: un atacante inyectando un iframe en HTML proporcionado por el usuario puede acceder a recursos internos de la red, incluyendo metadatos de instancia de AWS EC2 en 169.254.169.254, lo que potencialmente lleva a una toma completa de la infraestructura. CVE-2020-21365 (CVSS 7.5) permite recorrido de directorios para leer archivos locales.

La propia página de estado del mantenedor de wkhtmltopdf advierte: "No use wkhtmltopdf con ningún HTML no confiable." CiviCRM emitió CIVI-PSA-2024-01 recomendando la eliminación inmediata. Pantheon lo eliminó de PHP Runtime Gen 2 en 2025. A pesar de esto, wkhtmltopdf sigue integrado en bibliotecas envoltorias en todos los principales ecosistemas de lenguaje (pdfkit de Python, wicked_pdf de Ruby, KnpSnappy de PHP, DinkToPdf de .NET).

Rutas de migración: Puppeteer/Playwright para ejecución de JavaScript completa (equivalente funcional más cercano), WeasyPrint para pilas Python que no necesiten JS, Gotenberg para arquitecturas de microservicios, o DocRaptor/PrinceXML para necesidades de medios paginados CSS.

Los benchmarks de rendimiento revelan grandes compromisos de recursos

Los benchmarks independientes de Kyotu Technology y hardkoded.com proporcionan comparaciones cuantitativas:

Las imágenes Docker de WeasyPrint son dramáticamente más pequeñas con 200–400 MB, y el motor de renderizado no tiene dependencia de Chromium. Sin embargo, WeasyPrint es conocido por ser lento para documentos complejos— un PDF de 52 páginas tomó ~100 segundos en un benchmark, y tablas grandes (5,000+ filas) pueden consumir 1.4+ GB de RAM.

Para entornos sin servidor, la métrica crítica es el tiempo de arranque en frío. Las funciones de Lambda basadas en Chromium experimentan arranques en frío de 5 a 15 segundos debido a la descompresión binaria. Usar @sparticuz/chromium-min (~50 MB comprimido) con Puppeteer-core encaja dentro del límite de 250 MB de Lambda y reduce el tamaño del paquete de ~41 MB a ~769 KB. La concurrencia aprovisionada reduce los arranques en frío a ~400 ms pero incrementa el costo. La memoria de Lambda debe ser como mínimo 1,024 MB, idealmente 1,600 MB para generación PDF de Chromium fiable.

Las capacidades de seguridad varían drásticamente entre las herramientas

Solo iText e IronPDF proporcionan la trifecta de seguridad completa de cifrado, firmas digitales y redacción. iText Suite 9.5 está agregando algoritmos de firma resistentes a la post-cuántica para estar preparado para el futuro. Entre las APIs de la nube, DocRaptor (SOC 2, HIPAA) y Nutrient (SOC 2 Tipo II, HIPAA, WCAG 2.2) lideran en certificaciones de cumplimiento.

Problemas de implementación que cada equipo debería anticipar

Las fuentes son la causa n.º 1 de diferencias de renderización entre desarrollo y producción. Las imágenes Docker mínimas carecen por completo de fuentes, produciendo caracteres tofu (□) para texto no ASCII. La solución es instalar paquetes de fuentes integrales — la familia de fuentes Noto cubre prácticamente todos los sistemas de escritura. Para soporte de CJK, las fuentes-noto-cjk son esenciales. Las fuentes personalizadas deben copiarse en /usr/local/share/fonts/ y ejecutar fc-cache -f -v después.

El sandboxing de Chromium en Docker es el problema n.º 2 de implementación. Chromium requiere namespaces del kernel de Linux que los contenedores Docker suelen carecer, produciendo errores Running as root without --no-sandbox is not supported. La solución correcta en términos de seguridad es crear un usuario que no sea root (useradd -r pptruser); la solución expedita es --no-sandbox, lo que reduce la seguridad y solo debe usarse para contenido de confianza.

La acumulación de memoria es el asesino silencioso en procesos de Chromium de larga duración. La memoria aumenta con cada conversión, provocando eventualmente bloqueos OOM. Las mitigaciones críticas incluyen: aumentar la memoria compartida de Docker (--shm-size=512M, ya que el predeterminado de 64 MB causa bloqueos), usar --disable-dev-shm-usage, reiniciar instancias del navegador después de N conversiones (Gotenberg hace esto automáticamente después de 100) y usar dumb-init o Docker --init para eliminar procesos zombies. Una sola tabla HTML de 50,000 filas puede consumir 10+ GB de RAM en Chromium.

La temporización de JavaScript causa PDFs incompletos cuando el contenido dinámico no ha terminado de cargarse. Usa waitUntil: 'networkidle0' (espera por cero conexiones de red durante 500 ms) o page.waitForSelector('.data-loaded') para la preparación explícita de elementos. Gotenberg mitiga esto esperando por los eventos DomContent, Load, NetworkIdle y LoadingFinished por defecto, agregando un tiempo de latencia base de ~2 segundos pero asegurando la completitud.

Qué herramienta se adapta a qué caso de uso

Facturas y extractos: WeasyPrint (stacks de Python — ligero, excelente CSS Paged Media, sin sobrecarga de Chromium), Gotenberg (microservicio agnóstico de lenguaje) o pdfmake (documentos estructurados en cliente). Para .NET, IronPDF ofrece la API más ergonómica.

Informes y tableros con gráficos: Puppeteer o Playwright — solo los motores de navegador completos pueden ejecutar D3.js, Chart.js o Plotly nativamente. WeasyPrint no puede renderizar gráficos generados por JavaScript. El motor Chromium de IronPDF maneja esto dentro de las aplicaciones .NET sin lanzar procesos externos.

Renderización de SPA a PDF: Puppeteer o Playwright son las únicas opciones realistas. Los marcos modernos (React, Angular, Vue) requieren ejecución completa de navegador. La configuración de waitUntil es fundamental para asegurar que todo el contenido asincrónico haya cargado.

Cumplimiento y seguridad (PDF/A, firma digital, cifrado): iText (el más completo pero caro), IronPDF (.NET, características de seguridad amplias) o PDFreactor (Java, firma incorporada). Las herramientas basadas en Chromium requieren post-procesamiento externo para cualquier característica de seguridad.

Sin servidor y contenedores: Gotenberg (hecho a medida para contenedores, licencia MIT, imágenes de Cloud Run/Lambda) o Puppeteer-core + @sparticuz/chromium-min para AWS Lambda (50 MB comprimido, cabe dentro de los límites).

Publicación de calidad de impresión: PrinceXML o DocRaptor (API) — nada más se acerca a su fidelidad de CSS Paged Media para cabeceras corrientes, notas al pie, referencias cruzadas y tipografía profesional.

Procesamiento por lotes a escala: Gotenberg con escalado horizontal (múltiples contenedores detrás de un balanceador de carga), IronPDF con procesamiento por lotes asincrónico (RenderHtmlAsPdfAsync + Parallel.ForEach) o WeasyPrint con trabajadores de Celery para entornos Python.

Conclusión

El ecosistema de HTML a PDF en 2026 se ha madurado en niveles claramente diferenciados. Las herramientas basadas en Chromium han ganado la guerra de la fidelidad de renderización — su salida coincide con lo que los usuarios ven en Chrome, y manejan JavaScript moderno y CSS sin compromisos. Pero esta fidelidad tiene un costo de recursos que hace que las alternativas ligeras (WeasyPrint, pdfmake) sean atractivas para entornos limitados.

Tres ideas destacan de este análisis. Primero, la brecha entre las herramientas de Chromium y los motores de CSS Paged Media se está estrechando pero sigue siendo fundamental — si tus documentos necesitan cabeceras corrientes, notas al pie o distribuciones cuidadosas de páginas, PrinceXML, PDFreactor o WeasyPrint aún superan cualquier enfoque basado en navegador. En segundo lugar, la seguridad es una consideración secundaria en la mayoría de las herramientas — solo IronPDF e iText proporcionan cifrado, firmas y redacción en un solo paquete, mientras que todo el ecosistema de Chromium produce PDFs sin protección por defecto. En tercer lugar, la migración de wkhtmltopdf no es opcional — su vulnerabilidad SSRF de CVSS 9.8 es activamente explotable, y toda organización que aún lo use debería tratar el reemplazo como un incidente de seguridad, no como una solicitud de función.