Conversor gratuito de PDF a HTML

Acerca de la conversión PDF → HTML

Esta herramienta usa PDF.js para extraer el texto de archivos PDF y restituirlo en HTML semántico. Ideal para convertir documentos a un formato compatible con la web, archivar contenido o preparar texto para procesamiento posterior.

Casos de uso habituales

• Archivado de documentos · convierte PDF a HTML para una preservación digital a largo plazo y acceso web.
• Migración de contenido · extrae texto de PDF a HTML estructurado para un CMS o publicación web.
• Extracción de texto · obtén texto limpio a partir de PDF para analizar o reutilizar.
• Publicación web · convierte tus documentos a un formato compatible con la web para una carga rápida y una mejor accesibilidad.
• Procesamiento de datos · prepara el contenido PDF para una transformación o integración posterior.

Preguntas frecuentes

¿Qué tamaños de PDF se admiten?

Esta herramienta puede procesar PDF de hasta unos 10 MB según tu navegador. Los PDF muy voluminosos o complejos pueden tardar más en procesarse.

¿Conserva el formato del PDF?

La herramienta extrae el contenido textual y lo restituye en párrafos. Los diseños complejos, las imágenes y los estilos se simplifican a HTML limpio.

¿Puedo descargar el HTML?

Sí. Haz clic en «Descargar el HTML» para guardar el contenido convertido como archivo .html, abrible en cualquier navegador o editor.

Una breve historia del PDF, de PostScript a una página portátil

El Formato de Documento Portátil fue una idea de John Warnock, cofundador de Adobe Systems, que antes había coinventado PostScript, el lenguaje de descripción de páginas que, a partir de 1985 con la Apple LaserWriter, hizo posible la autoedición. PostScript era extraordinariamente potente, pero era un lenguaje de programación, no un formato de documento: un archivo PostScript describía cómo representar una página cuando se introducía en un intérprete, pero en realidad no estaba pensado para leerse, editarse ni representarse de forma coherente en máquinas que carecían de las fuentes adecuadas.

En 1991, Warnock hizo circular una nota interna de Adobe que llegó a conocerse como el Proyecto Camelot. La premisa: Adobe debía crear un único formato de archivo capaz de capturar cualquier documento (incluidas sus fuentes, su maquetación, sus gráficos vectoriales y sus imágenes) y reproducirlo de forma idéntica en cualquier ordenador, en cualquier sistema operativo, con independencia de qué aplicación lo hubiera creado originalmente. Cuando la propuesta quedó perfilada, el proyecto ya tenía un nombre de producto: Adobe Acrobat.

Acrobat 1.0 y PDF 1.0 se presentaron en la feria Comdex Fall de Las Vegas en noviembre de 1992 y se entregaron a los clientes en junio de 1993. La decisión comercial decisiva de Adobe llegó en 1994, cuando empezó a regalar Acrobat Reader, un movimiento que reflejaba lo que había ocurrido con los navegadores de HTML y sembró una base de millones de instalaciones. El formato pasó por varias revisiones: PDF 1.1 (1996, enlaces externos y seguridad), 1.2 (1996, AcroForms), 1.3 (2000, firmas digitales), 1.4 (2001, transparencia), 1.5 (2003, flujos de objetos y JPEG 2000), 1.6 (2004, OpenType y 3D), 1.7 (2006). En 2008, PDF 1.7 se publicó como ISO 32000-1:2008; le siguió PDF 2.0 como ISO 32000-2:2017, con una segunda edición sustancialmente revisada (ISO 32000-2:2020) que incorporó erratas y es la referencia autorizada actual.

Junto a la norma principal existen varios perfiles de PDF especializados: PDF/A (ISO 19005-1:2005, con -2 en 2011 y -3 en 2012) es el perfil de archivo que prohíbe las funciones que dependen de recursos externos o de software futuro (sin JavaScript, sin audio, sin cifrado; las fuentes deben ir incrustadas); PDF/X es el perfil de preimpresión que usa la industria de la impresión; PDF/E es el perfil de ingeniería para dibujos técnicos; PDF/UA (ISO 14289-1:2014) es el perfil de accesibilidad universal que exige estructura lógica y etiquetado para que los lectores de pantalla puedan presentar el contenido en el orden de lectura; PDF/VT es el perfil variable y transaccional que se usa en la combinación de correspondencia personalizada.

Por qué la conversión de PDF a HTML es estructuralmente difícil

Un PDF es, en su nivel más bajo, un conjunto de objetos numerados (diccionarios, matrices, cadenas, números, nombres y flujos binarios) dispuestos con una tabla de referencias cruzadas al final que permite a un lector saltar a cualquier objeto sin analizar todo el archivo. Los objetos forman un árbol que arranca en un objeto Catalog que apunta a un árbol Pages, que contiene objetos Page. Cada Page hace referencia a un flujo de contenido: las instrucciones reales que dibujan la página.

Un flujo de contenido es una secuencia de operadores gráficos compactos en un pequeño lenguaje emparentado con PostScript, pero no Turing-completo. Para el texto, usa Tf (fijar fuente y tamaño), Td (mover la posición del texto), Tm (fijar la matriz de texto), Tj (mostrar una cadena), TJ (mostrar una matriz de cadenas con desplazamientos individuales opcionales de los caracteres para el kerning) y ET (fin del texto). El punto crucial es que todo es posicional. Un párrafo de texto corrido no se almacena como un párrafo. Se almacena como una serie de comandos Tj o TJ, cada uno de los cuales dibuja un glifo o una breve serie de glifos en una coordenada x e y concreta de la página. No existe la noción de frase, párrafo, encabezado, lista o columna, solo la cuestión de dónde se sitúa físicamente cada carácter.

El HTML es lo inverso: un árbol fluido de elementos semánticos en el que la maquetación es responsabilidad del motor de representación y el mismo HTML puede readaptarse para ajustarse a un teléfono, un ordenador de escritorio o un lector de pantalla. Por tanto, convertir PDF a HTML exige aplicar ingeniería inversa a una estructura que el PDF nunca tuvo obligación de registrar. Un conversor tiene que observar la distribución espacial del texto en cada página e inferir:

• qué caracteres pertenecen a la misma palabra (midiendo el hueco entre glifos frente al ancho de avance medio de la fuente);
• qué palabras pertenecen a la misma línea (agrupándolas por la coordenada y dentro de una tolerancia);
• qué líneas pertenecen al mismo párrafo (detectando diferencias de línea base y patrones de sangría);
• qué párrafos pertenecen a la misma columna (encontrando canales verticales de espacio en blanco);
• y el orden de lectura a través de varias columnas, notas al pie y notas al margen.

Nada de esto se resuelve leyendo el flujo de contenido en orden, porque el orden del flujo no es necesariamente el orden de lectura. Un motor de maquetación que generó el PDF pudo haber dibujado los elementos en el orden más eficiente para la representación, que puede ser de arriba abajo en zigzag, o por fuente, o por color. El texto de un solo párrafo puede entremezclarse con el texto de los párrafos vecinos en el flujo subyacente. Por eso los extractores de PDF que simplemente concatenan cadenas en el orden del flujo producen resultados desordenados para cualquier cosa más compleja que una novela de una sola columna.

Si el PDF se ha etiquetado: es decir, si su autor incluyó un árbol de estructura junto al contenido visual, la tarea se vuelve mucho más fácil. Un PDF etiquetado incluye una jerarquía de elementos de estructura (P para párrafo, de H1 a H6 para encabezados, L para lista, LI para elemento de lista, Table, TR, TD, Figure, Caption) que reflejan el vocabulario semántico de HTML. PDF/UA exige el etiquetado por accesibilidad precisamente porque los PDF sin etiquetar son esencialmente opacos para la tecnología de asistencia. En la práctica, sin embargo, la mayoría de los PDF que circulan no están etiquetados, o lo están mal por la herramienta de creación, de modo que un conversor robusto tiene que recurrir al análisis de maquetación incluso cuando hay etiquetas.

Las principales bibliotecas de representación de PDF de código abierto

PDF.js es la biblioteca de JavaScript escrita por Mozilla, lanzada originalmente en junio de 2011 como proyecto experimental dirigido por Andreas Gal. Analiza y representa los PDF por completo en el navegador mediante el lienzo de HTML5 y JavaScript, sin necesidad de un complemento nativo. PDF.js se integró en Firefox como visor de PDF predeterminado a partir de Firefox 19, en marzo de 2013, en sustitución del complemento de Adobe Reader. Expone una API de JavaScript que permite a una página extraer el contenido de texto con metadatos posicionales (cada fragmento de texto se devuelve con su x, y, anchura, altura, nombre de fuente y tamaño de fuente). Esta herramienta está construida sobre PDF.js.

Poppler es una biblioteca de C++ bifurcada de xpdf, el veterano visor de PDF que Glyph and Cog mantiene desde finales de la década de 1990. Poppler impulsa las funciones de representación de PDF de los entornos de escritorio de Linux (Evince en GNOME, Okular en KDE), las utilidades de línea de comandos pdftotext y pdftohtml y muchas canalizaciones de procesamiento de PDF del lado del servidor. MuPDF, de Artifex Software (la misma empresa que mantiene Ghostscript), es una biblioteca de C más pequeña y rápida orientada al uso embebido. PDFium es el motor que se incluye dentro de Google Chrome y Microsoft Edge para la visualización integrada de PDF; es una bifurcación del SDK propietario Foxit PDF que Google y Foxit liberaron conjuntamente como código abierto en mayo de 2015. qpdf es una biblioteca de C++ y una herramienta de línea de comandos centrada en la manipulación estructural más que en la representación: puede descomprimir, cifrar, descifrar, linealizar y reescribir PDF sin cambiar su contenido visual.

Para producir específicamente una salida en HTML, el proyecto más importante creado para tal fin es pdf2htmlEX, escrito originalmente por Lu Wang en 2012 y mantenido ahora por un grupo comunitario. pdf2htmlEX adopta un enfoque distinto al de la mayoría de los conversores: en lugar de intentar reconstruir un HTML semántico, reproduce la maquetación visual del PDF con la mayor fidelidad posible emitiendo elementos div posicionados de forma absoluta para cada fragmento de texto, incrustando las fuentes originales como archivos Web Open Font Format (WOFF) y usando transformaciones CSS cuando es necesario. El resultado es una página web de aspecto indistinguible del PDF original, pero el HTML subyacente es un muro de spans position: absolute sin significado semántico.

Fidelidad de maquetación frente a flujo semántico: el compromiso central

Este es el compromiso central en la conversión de PDF a HTML: puedes tener fidelidad de maquetación o puedes tener flujo semántico, pero es difícil tener ambos. Un conversor que prioriza la fidelidad, como pdf2htmlEX, produce una salida que se imprime y se ve como el original, pero es opaca para un lector de pantalla y rígida en la pantalla de un teléfono. Un conversor que prioriza el flujo, como pdftotext o el getTextContent de PDF.js seguido de una sencilla reconstrucción de párrafos, produce un HTML limpio, legible y accesible, pero pierde la riqueza visual del original: los colores, las fuentes exactas, la colocación de las imágenes, las cuadrículas de las tablas y todo sentido de la página original.

La herramienta de Absolutool se sitúa con claridad en el lado del flujo. Extrae el contenido de texto mediante PDF.js y lo emite como párrafos, dando prioridad a la legibilidad, la accesibilidad y un tamaño de archivo pequeño por encima de una reproducción perfecta al píxel. Si necesitas la vía de la reproducción visual (cada glifo en su posición original, las fuentes originales incrustadas, la paginación exacta conservada), pdf2htmlEX es la herramienta que conviene mirar; si necesitas la vía de los párrafos legibles (reutilización de contenido, publicación web, HTML indexable por buscadores, salida accesible para lectores de pantalla), esta herramienta cumple su propósito.

Fuentes incrustadas, imágenes y el contenido vectorial subyacente

Un PDF puede incrustar cualquier fuente que desee, y un conversor que quiera preservar el aspecto original tiene tres opciones. Incrustar y servir: el conversor extrae cada fuente incrustada del PDF, la reempaqueta como fuente web en un formato que los navegadores entienden (WOFF o, desde 2018, WOFF2 con su compresión Brotli más agresiva) y la enlaza desde el HTML generado. Esto preserva el aspecto original, pero infla el tamaño del archivo y puede toparse con problemas de licencia si los derechos de incrustación de la fuente no se extienden a la redistribución web. Sustituir: asignar cada fuente incrustada a una fuente del sistema similar (una fuente PDF con serifa podría convertirse en Times New Roman o Georgia), aceptando cierta desviación visual a cambio de una salida más pequeña y limpia. Ignorar: descartar por completo la información de las fuentes y dejar que el navegador aplique una fuente de texto predeterminada, que es lo que hacen la mayoría de los conversores que priorizan el flujo, porque el usuario lee el HTML con el estilo normal del navegador.

Las imágenes plantean una elección similar. Un conversor puede extraer las imágenes incrustadas como archivos separados y referenciarlas desde el HTML; rasterizar páginas enteras como imágenes e incrustarlas en línea (convirtiendo el PDF en una galería con pretensiones); o descartar las imágenes por completo y emitir solo texto, que es la opción que toma esta herramienta, apropiada para la reutilización de contenido más que para la reproducción visual. El contenido vectorial (líneas, formas y trazados dibujados por los operadores gráficos del PDF) resulta aún más incómodo, porque no hay una forma limpia de representarlo en HTML semántico; los conversores que quieren preservarlo suelen recurrir a SVG en línea o a la rasterización en PNG.

Cuando el PDF es una imagen: recurso a OCR para documentos escaneados

Una fracción significativa de los PDF que circulan no son en realidad documentos en el sentido estructurado, sino imágenes escaneadas de documentos en papel, empaquetadas en envoltorios PDF porque el PDF es el formato universal para enviar cosas con aspecto de papel por internet. Un PDF escaneado no tiene flujo de contenido de texto; cada página es una única imagen rasterizada incrustada que resulta representar texto, pero no lo contiene como caracteres legibles por máquina. Extraer texto de un PDF así requiere reconocimiento óptico de caracteres (OCR), que es una operación fundamentalmente distinta de la extracción de texto.

El motor de OCR de código abierto dominante es Tesseract, desarrollado originalmente en HP Labs entre 1985 y 1995, liberado como código abierto en 2005 y mantenido por Google desde 2006 hasta que Google cedió la tutela principal a un grupo comunitario hacia 2018. Tesseract admite más de cien idiomas, se ejecuta en todas las plataformas principales e impulsa las funciones de OCR de innumerables herramientas de escritorio y de servidor. El framework Vision de Apple, disponible en macOS e iOS desde 2017, incluye una API de reconocimiento de texto rápida y precisa que usan las apps integradas de capturas de pantalla y fotos del sistema operativo. Google Cloud Vision, Azure Computer Vision y Amazon Textract son los principales servicios de OCR en la nube; para documentos en concreto, tanto Textract como Document Intelligence de Azure van más allá del OCR puro y reconocen tablas, pares clave-valor y campos de formulario.

Un conversor de PDF a HTML basado en navegador que se ejecuta por completo del lado del cliente no puede, por lo general, realizar OCR: los modelos de OCR pesan como mínimo decenas de megabytes y la inferencia es demasiado lenta para ejecutarse de forma interactiva en el portátil de un usuario. Si tu PDF contiene páginas escaneadas sin texto extraíble, esta herramienta producirá una salida vacía para esas páginas, y el siguiente paso adecuado es una herramienta de OCR aparte o un servicio del lado del servidor.

Por qué la gente convierte PDF a HTML

Los casos de uso se reducen a un puñado de patrones recurrentes:

• Editoriales con archivos de informes antiguos: informes anuales, libros blancos, artículos de investigación, publicaciones gubernamentales y manuales técnicos; convierten los PDF a HTML para que el contenido pueda leerse directamente en un navegador sin obligar a cada visitante a descargar un archivo. Las versiones en HTML son más fáciles de navegar (puedes enlazar a una sección concreta), se cargan más rápido en un teléfono y son rastreables por los buscadores.
• Los blogueros y los especialistas en marketing de contenidos convierten a HTML los PDF que han creado o licenciado para poder volver a publicar el contenido como artículos, reaprovechando el texto sin volver a teclearlo.
• Los archiveros web convierten los PDF a HTML como parte de proyectos de preservación, partiendo de la idea de que el HTML es más duradero a lo largo de las décadas que un formato binario complejo cuya especificación tiene varios miles de páginas.
• Las apps de lectura móvil y los servicios de lectura diferida convierten los PDF a HTML para que los artículos se abran en sus vistas de lectura, con la fuente y el tamaño de fuente preferidos del usuario, el modo oscuro y una longitud de línea ajustable.
• Los usuarios de lectores de pantalla convierten los PDF a HTML porque los PDF sin etiquetar son esencialmente opacos para la tecnología de asistencia, pero una representación en HTML con párrafos y encabezados adecuados puede leerse en voz alta con claridad.
• Los flujos de gestión del conocimiento convierten los PDF a HTML para introducir el contenido en índices de búsqueda, bases de datos de texto completo y ventanas de contexto de grandes modelos de lenguaje, ninguno de los cuales entiende de forma nativa el formato PDF, pero todos los cuales manejan bien el texto plano y el HTML.
• Los investigadores y académicos extraen texto de los PDF de artículos de revistas para introducirlo en gestores de citas, bases de datos de referencias o canalizaciones de minería de textos que buscan patrones en miles de artículos.

Cada uno de estos casos tiene requisitos ligeramente distintos, pero comparten un hilo común: el usuario quiere el contenido del PDF (las palabras, la estructura, el significado) sin verse limitado por el rígido formato sujeto a la página que eligió el documento original.

Más preguntas

¿Por qué mi HTML convertido se ve distinto del PDF original?

Esta herramienta prioriza el flujo: extrae el texto y emite párrafos limpios con la fuente predeterminada de tu navegador, dando prioridad a la legibilidad, la accesibilidad y la indexabilidad por buscadores por encima de la fidelidad visual. Si necesitas una reproducción perfecta al píxel de la maquetación original (fuentes incrustadas, posicionamiento exacto, colores originales), fíjate en herramientas que priorizan la fidelidad, como pdf2htmlEX, que emite elementos div posicionados de forma absoluta que coinciden visualmente con el PDF de origen, pero producen un HTML esencialmente ilegible para los lectores de pantalla y rígido en las pantallas de los teléfonos.

¿Por qué mi PDF de varias columnas sale desordenado?

El PDF no almacena el orden de lectura, solo las posiciones. Un conversor tiene que inferir los límites de las columnas a partir de la distribución espacial del texto. Para maquetaciones sencillas de dos columnas, la heurística suele funcionar; para maquetaciones complejas con notas al margen, notas al pie que se entremezclan con el texto corrido o texto que cruza el canal entre columnas, puede producir una salida desordenada. Si tienes un PDF etiquetado (uno que incluye un árbol de estructura), la precisión es muchísimo mejor; para los PDF sin etiquetar, el resultado depende de lo claramente que las columnas estén separadas físicamente por espacio en blanco.

Mi PDF está escaneado (solo imágenes), ¿por qué no se extrae nada?

Un PDF escaneado no tiene contenido de texto: cada página es una imagen rasterizada de texto, no texto que el analizador pueda leer. Extraer texto requiere OCR (Tesseract, Google Cloud Vision, el framework Vision de Apple, etc.), que es una operación fundamentalmente distinta del análisis de PDF. Esta herramienta no incluye un motor de OCR porque los modelos son demasiado grandes para distribuirse con una herramienta de navegador. El siguiente paso adecuado es un servicio de OCR especializado o una herramienta de escritorio con OCR integrado.

¿Puedo convertir un PDF protegido con contraseña?

Si el PDF tiene una contraseña de apertura (necesitas escribir una contraseña solo para verlo), PDF.js lanzará un error en lugar de convertirlo. Si el PDF solo tiene una contraseña de permisos (abrirlo es libre, pero imprimir o copiar están restringidos), el comportamiento varía: la mayoría de las compilaciones modernas de PDF.js respetan los permisos y pueden negarse a extraer texto. En cualquier caso, la vía más limpia es eliminar primero la protección en la herramienta de PDF original y convertir después. Eliminar la protección de un PDF que posees legalmente está bien; hacerlo en un PDF que no es tuyo puede que no lo esté.

Herramientas relacionadas