Convertisseur PDF → HTML, gratuit

À propos de la conversion PDF → HTML

Cet outil utilise PDF.js pour extraire le texte de fichiers PDF et le restitue en HTML sémantique. Idéal pour convertir des documents en format web-compatible, archiver du contenu ou préparer du texte pour un traitement ultérieur.

Cas d'usage courants

• Archivage de documents · convertissez des PDF en HTML pour une préservation numérique à long terme et un accès web.
• Migration de contenu · extrayez du texte de PDF vers du HTML structuré pour un CMS ou une publication web.
• Extraction de texte · obtenez du texte propre à partir de PDF pour analyse ou réutilisation.
• Publication web · convertissez vos documents en format web-compatible pour un chargement rapide et une meilleure accessibilité.
• Traitement de données · préparez le contenu PDF pour une transformation ou intégration ultérieure.

Questions fréquentes

Quelles tailles de PDF sont prises en charge ?

Cet outil peut traiter des PDF jusqu'à environ 10 Mo selon votre navigateur. Les PDF très volumineux ou complexes peuvent prendre plus de temps à traiter.

Conserve-t-il la mise en forme du PDF ?

L'outil extrait le contenu textuel et le restitue en paragraphes. Les mises en page complexes, les images et les styles sont simplifiés en HTML propre.

Puis-je télécharger le HTML ?

Oui. Cliquez sur « Télécharger le HTML » pour enregistrer le contenu converti en fichier .html, ouvrable dans tout navigateur ou éditeur.

Une brève histoire du PDF, de PostScript à la page portable

Le Portable Document Format est né de l'imagination de John Warnock, cofondateur d'Adobe Systems, qui avait auparavant co-inventé PostScript, le langage de description de page qui, à partir de 1985 avec l'Apple LaserWriter, a rendu possible la publication assistée par ordinateur. PostScript était extraordinairement puissant, mais c'était un langage de programmation, et non un format de document : un fichier PostScript décrivait comment afficher une page lorsqu'on le fournissait à un interpréteur, mais il n'était pas vraiment destiné à être lu, modifié ou rendu de façon cohérente sur des machines dépourvues des bonnes polices.

En 1991, Warnock fit circuler une note interne d'Adobe qui devint connue sous le nom de projet Camelot. Le principe : Adobe devait construire un format de fichier unique capable de capturer n'importe quel document (y compris ses polices, sa mise en page, ses graphiques vectoriels et ses images) et de le reproduire à l'identique sur n'importe quel ordinateur, sous n'importe quel système d'exploitation, quelle que soit l'application qui l'avait créé à l'origine. Lorsque la proposition eut été affinée, le projet avait un nom de produit : Adobe Acrobat.

Acrobat 1.0 et PDF 1.0 furent présentés au salon professionnel Comdex Fall à Las Vegas en novembre 1992 et livrés aux clients en juin 1993. La décision commerciale décisive d'Adobe survint en 1994, lorsque l'entreprise se mit à distribuer gratuitement Acrobat Reader, un geste qui reproduisait ce qui s'était passé avec les navigateurs HTML et qui amorça une base de millions d'installations. Le format connut plusieurs révisions : PDF 1.1 (1996, liens externes et sécurité), 1.2 (1996, AcroForms), 1.3 (2000, signatures numériques), 1.4 (2001, transparence), 1.5 (2003, flux d'objets et JPEG 2000), 1.6 (2004, OpenType et 3D), 1.7 (2006). En 2008, PDF 1.7 fut publié sous la référence ISO 32000-1:2008 ; PDF 2.0 suivit sous ISO 32000-2:2017, avec une deuxième édition substantiellement révisée (ISO 32000-2:2020) qui a intégré des errata et constitue la référence faisant actuellement autorité.

Plusieurs profils PDF spécialisés coexistent avec la norme principale : PDF/A (ISO 19005-1:2005, avec -2 en 2011 et -3 en 2012) est le profil d'archivage qui interdit les fonctionnalités dépendant de ressources externes ou de logiciels futurs (pas de JavaScript, pas d'audio, pas de chiffrement, les polices doivent être intégrées) ; PDF/X est le profil de prépresse utilisé par l'industrie de l'impression ; PDF/E est le profil d'ingénierie pour les dessins techniques ; PDF/UA (ISO 14289-1:2014) est le profil d'accessibilité universelle qui exige une structure logique et un balisage afin que les lecteurs d'écran puissent présenter le contenu dans l'ordre de lecture ; PDF/VT est le profil variable-et-transactionnel utilisé dans le publipostage personnalisé.

Pourquoi la conversion de PDF en HTML est structurellement difficile

Un PDF est, à son niveau le plus bas, un ensemble d'objets numérotés (dictionnaires, tableaux, chaînes, nombres, noms et flux binaires) disposés avec une table de références croisées à la fin, qui permet à un lecteur d'accéder directement à n'importe quel objet sans analyser tout le fichier. Les objets forment un arbre enraciné dans un objet Catalog qui pointe vers un arbre Pages, lequel contient des objets Page. Chaque Page référence un flux de contenu : les instructions concrètes qui dessinent la page.

Un flux de contenu est une séquence d'opérateurs graphiques compacts dans un petit langage apparenté à PostScript, mais non Turing-complet. Pour le texte, il utilise Tf (définir la police et la taille), Td (déplacer la position du texte), Tm (définir la matrice de texte), Tj (afficher une chaîne), TJ (afficher un tableau de chaînes avec des décalages individuels facultatifs entre caractères pour le crénage) et ET (fin du texte). Le point crucial est que tout est positionnel. Un paragraphe de texte courant n'est pas stocké comme un paragraphe. Il est stocké sous la forme d'une série de commandes Tj ou TJ, chacune dessinant un glyphe ou une courte suite de glyphes à une coordonnée x et y précise sur la page. Il n'existe aucune notion de phrase, de paragraphe, de titre, de liste ou de colonne, seulement la question de savoir où chaque caractère se situe physiquement.

Le HTML est l'inverse : un arbre fluide d'éléments sémantiques où la mise en page relève de la responsabilité du moteur de rendu et où le même HTML peut se redistribuer pour s'adapter à un téléphone, à un ordinateur de bureau ou à un lecteur d'écran. Convertir un PDF en HTML exige donc de reconstituer par rétro-ingénierie une structure que le PDF n'a jamais été tenu d'enregistrer. Un convertisseur doit examiner la distribution spatiale du texte sur chaque page et inférer :

• quels caractères appartiennent au même mot (en mesurant l'espace entre les glyphes par rapport à la chasse moyenne de la police) ;
• quels mots appartiennent à la même ligne (en les regroupant selon la coordonnée y dans une certaine tolérance) ;
• quelles lignes appartiennent au même paragraphe (en détectant les différences de ligne de base et les motifs d'indentation) ;
• quels paragraphes appartiennent à la même colonne (en repérant les gouttières verticales d'espace blanc) ;
• et l'ordre de lecture à travers plusieurs colonnes, notes de bas de page et notes de marge.

Rien de tout cela ne se résout en lisant le flux de contenu dans l'ordre, car l'ordre du flux n'est pas nécessairement l'ordre de lecture. Un moteur de mise en page qui a produit le PDF peut avoir dessiné les éléments dans l'ordre le plus efficace pour le rendu, qui peut être de haut en bas en zigzag, ou par police, ou par couleur. Le texte d'un même paragraphe peut être entrelacé avec le texte de paragraphes voisins dans le flux sous-jacent. C'est pourquoi les extracteurs de PDF qui se contentent de concaténer les chaînes dans l'ordre du flux produisent une sortie déformée pour tout ce qui est plus complexe qu'un roman à une seule colonne.

Si le PDF a été balisé : c'est-à-dire si son auteur a inclus un arbre de structure aux côtés du contenu visuel, la tâche devient bien plus simple. Un PDF balisé comprend une hiérarchie d'éléments de structure (P pour paragraphe, H1 à H6 pour les titres, L pour liste, LI pour élément de liste, Table, TR, TD, Figure, Caption) qui reflètent le vocabulaire sémantique du HTML. PDF/UA impose le balisage pour l'accessibilité, précisément parce que les PDF non balisés sont essentiellement opaques pour les technologies d'assistance. En pratique, toutefois, la majorité des PDF que l'on rencontre ne sont pas balisés, ou sont mal balisés par l'outil de création, de sorte qu'un convertisseur robuste doit se rabattre sur l'analyse de la mise en page même lorsque des balises sont présentes.

Les principales bibliothèques open source de rendu PDF

PDF.js est la bibliothèque JavaScript écrite par Mozilla, lancée à l'origine en juin 2011 comme projet expérimental dirigé par Andreas Gal. Elle analyse et affiche les PDF entièrement dans le navigateur à l'aide du canevas HTML5 et de JavaScript, sans aucun module d'extension natif. PDF.js a été intégrée à Firefox comme visionneuse PDF par défaut à partir de Firefox 19, en mars 2013, remplaçant le module Adobe Reader. Elle expose une API JavaScript qui permet à une page d'extraire le contenu textuel avec des métadonnées de position (chaque suite de texte est renvoyée avec ses x, y, largeur, hauteur, nom de police et taille de police). Cet outil repose sur PDF.js.

Poppler est une bibliothèque C++ dérivée de xpdf, la vénérable visionneuse PDF que Glyph and Cog maintient depuis la fin des années 1990. Poppler alimente les fonctions de rendu PDF des environnements de bureau Linux (Evince sous GNOME, Okular sous KDE), les utilitaires en ligne de commande pdftotext et pdftohtml, ainsi que de nombreuses chaînes de traitement PDF côté serveur. MuPDF, d'Artifex Software (la même entreprise qui maintient Ghostscript), est une bibliothèque C plus petite et plus rapide destinée à un usage embarqué. PDFium est le moteur intégré à Google Chrome et à Microsoft Edge pour l'affichage PDF natif ; c'est une dérivation du SDK PDF propriétaire de Foxit que Google et Foxit ont ouvert conjointement en mai 2015. qpdf est une bibliothèque C++ et un outil en ligne de commande axés sur la manipulation structurelle plutôt que sur le rendu ; il peut décompresser, chiffrer, déchiffrer, linéariser et réécrire des PDF sans modifier leur contenu visuel.

Pour produire spécifiquement une sortie HTML, le projet dédié le plus important est pdf2htmlEX, écrit à l'origine par Lu Wang en 2012 et désormais maintenu par un groupe communautaire. pdf2htmlEX adopte une approche différente de la plupart des convertisseurs : au lieu d'essayer de reconstruire un HTML sémantique, il reproduit la mise en page visuelle du PDF aussi fidèlement que possible en émettant des éléments div positionnés en absolu pour chaque suite de texte, en intégrant les polices d'origine sous forme de fichiers Web Open Font Format (WOFF) et en recourant aux transformations CSS lorsque c'est nécessaire. Le résultat est une page web impossible à distinguer du PDF d'origine, mais le HTML sous-jacent est un mur de balises position: absolute dénuées de toute signification sémantique.

Fidélité de la mise en page contre flux sémantique, le compromis central

C'est là le compromis central de la conversion de PDF en HTML : vous pouvez avoir la fidélité de la mise en page ou le flux sémantique, mais il est difficile d'avoir les deux. Un convertisseur privilégiant la fidélité comme pdf2htmlEX produit une sortie qui s'imprime et ressemble à l'original, mais qui est opaque pour un lecteur d'écran et rigide sur l'écran d'un téléphone. Un convertisseur privilégiant le flux comme pdftotext, ou la fonction getTextContent de PDF.js suivie d'une simple reconstruction des paragraphes, produit un HTML propre, lisible et accessible, mais perd la richesse visuelle de la source : couleurs, polices exactes, placement des images, grilles de tableaux et toute notion de la page d'origine.

L'outil Absolutool se place résolument du côté du flux. Il extrait le contenu textuel à l'aide de PDF.js et l'émet sous forme de paragraphes, en privilégiant la lisibilité, l'accessibilité et une taille de fichier réduite plutôt qu'une reproduction au pixel près. Si vous avez besoin de la voie de la reproduction visuelle (chaque glyphe à sa position d'origine, polices d'origine intégrées, pagination exacte préservée), c'est vers pdf2htmlEX qu'il faut se tourner ; si vous avez besoin de la voie des paragraphes lisibles (réutilisation du contenu, publication web, HTML indexable par les moteurs de recherche, sortie accessible aux lecteurs d'écran), cet outil est tout indiqué.

Polices intégrées, images et le contenu vectoriel sous-jacent

Un PDF peut intégrer la police de son choix, et un convertisseur soucieux de préserver l'apparence d'origine dispose de trois options. Intégrer et servir : le convertisseur extrait chaque police intégrée du PDF, la reconditionne en police web dans un format compris par les navigateurs (WOFF ou, depuis 2018, WOFF2 et sa compression Brotli plus agressive), et la référence depuis le HTML généré. Cela préserve l'apparence d'origine, mais gonfle la taille du fichier et peut se heurter à des problèmes de licence si les droits d'intégration de la police ne s'étendent pas à la redistribution sur le web. Substituer : faire correspondre chaque police intégrée à une police système similaire (une police PDF à empattement peut devenir Times New Roman ou Georgia), en acceptant une certaine dérive visuelle en échange d'une sortie plus légère et plus propre. Ignorer : écarter entièrement les informations de police et laisser le navigateur appliquer une police de corps par défaut, ce que font la plupart des convertisseurs privilégiant le flux, puisque l'utilisateur lit le HTML dans la mise en forme normale du navigateur.

Les images présentent un choix analogue. Un convertisseur peut extraire les images intégrées sous forme de fichiers séparés et les référencer depuis le HTML ; rastériser des pages entières en images et les intégrer en ligne (transformant le PDF en une galerie d'images sophistiquée) ; ou écarter entièrement les images et n'émettre que du texte, ce qui est le choix de cet outil, adapté à la réutilisation du contenu plutôt qu'à la reproduction visuelle. Le contenu vectoriel (lignes, formes, tracés dessinés par les opérateurs graphiques du PDF) est encore plus délicat, car il n'existe aucun moyen propre de le représenter en HTML sémantique ; les convertisseurs qui souhaitent le préserver tendent à se rabattre sur le SVG en ligne ou sur une rastérisation en PNG.

Quand le PDF est une image : le recours à l'OCR pour les documents numérisés

Une fraction importante des PDF que l'on rencontre ne sont pas vraiment des documents au sens structuré du terme : ce sont des images numérisées de documents papier, emballées dans des enveloppes PDF parce que le PDF est le format universel pour envoyer des objets de type papier sur Internet. Un PDF numérisé n'a aucun flux de contenu textuel ; chaque page est une unique image matricielle intégrée qui représente du texte sans pour autant le contenir sous forme de caractères lisibles par machine. Extraire le texte d'un tel PDF nécessite la reconnaissance optique de caractères (OCR), une opération fondamentalement différente de l'extraction de texte.

Le moteur OCR open source dominant est Tesseract, développé à l'origine chez HP Labs entre 1985 et 1995, passé en open source en 2005, et maintenu par Google de 2006 jusqu'à ce que Google en confie la gérance principale à un groupe communautaire vers 2018. Tesseract prend en charge plus d'une centaine de langues, fonctionne sur toutes les grandes plateformes et alimente les fonctions d'OCR d'innombrables outils de bureau et serveur. Le framework Vision d'Apple, disponible sur macOS et iOS depuis 2017, comprend une API de reconnaissance de texte rapide et précise, utilisée par les applications intégrées de capture d'écran et de photos du système. Google Cloud Vision, Azure Computer Vision et Amazon Textract sont les principaux services OCR en nuage ; pour les documents en particulier, Textract et Document Intelligence d'Azure vont tous deux au-delà de l'OCR brut pour reconnaître les tableaux, les paires clé-valeur et les champs de formulaire.

Un convertisseur PDF-vers-HTML basé sur le navigateur et fonctionnant entièrement côté client ne peut généralement pas effectuer d'OCR : les modèles d'OCR pèsent des dizaines de mégaoctets au minimum et l'inférence est trop lente pour s'exécuter de façon interactive sur l'ordinateur portable d'un utilisateur. Si votre PDF contient des pages numérisées sans texte extractible, cet outil produira une sortie vide pour ces pages, et la bonne étape suivante est un outil d'OCR distinct ou un service côté serveur.

Pourquoi convertir des PDF en HTML

Les cas d'usage se rangent dans une poignée de schémas récurrents :

• Les éditeurs possédant des archives d'anciens rapports : rapports annuels, livres blancs, articles de recherche, publications gouvernementales, manuels techniques, convertissent les PDF en HTML afin que le contenu puisse être lu directement dans un navigateur sans contraindre chaque visiteur à télécharger un fichier. Les versions HTML sont plus faciles à parcourir (on peut créer un lien vers une section précise), plus rapides à charger sur un téléphone et explorables par les moteurs de recherche.
• Les blogueurs et les responsables du marketing de contenu convertissent en HTML des PDF qu'ils ont rédigés ou pour lesquels ils détiennent une licence, afin de republier le contenu sous forme d'articles, réutilisant le texte sans avoir à le ressaisir.
• Les archivistes du web convertissent les PDF en HTML dans le cadre de projets de préservation, partant du principe que le HTML est plus durable au fil des décennies qu'un format binaire complexe dont la spécification compte plusieurs milliers de pages.
• Les applications de lecture mobile et les services de lecture différée convertissent les PDF en HTML pour que les articles s'ouvrent dans leur mode lecture, avec la police et la taille de police préférées de l'utilisateur, le mode sombre et une longueur de ligne ajustable.
• Les utilisateurs de lecteurs d'écran convertissent les PDF en HTML parce que les PDF non balisés sont essentiellement opaques pour les technologies d'assistance, alors qu'un rendu HTML doté de paragraphes et de titres en bonne et due forme peut être lu à voix haute proprement.
• Les flux de travail de gestion des connaissances convertissent les PDF en HTML pour alimenter en contenu les index de recherche, les bases de données en texte intégral et les fenêtres de contexte des grands modèles de langage, dont aucun ne comprend nativement le format PDF, mais qui gèrent tous bien le texte brut et le HTML.
• Les chercheurs et les universitaires extraient le texte de PDF d'articles de revues pour alimenter des gestionnaires de citations, des bases de données bibliographiques ou des chaînes de fouille de textes qui recherchent des motifs à travers des milliers d'articles.

Chacun de ces cas a des exigences légèrement différentes, mais ils partagent un fil conducteur : l'utilisateur veut le contenu du PDF (les mots, la structure, le sens) sans être contraint par le format rigide, lié à la page, qu'a choisi le document d'origine.

Plus de questions

Pourquoi mon HTML converti a-t-il un aspect différent du PDF d'origine ?

Cet outil privilégie le flux : il extrait le texte et émet des paragraphes propres dans la police par défaut de votre navigateur, en privilégiant la lisibilité, l'accessibilité et l'indexabilité par les moteurs de recherche plutôt que la fidélité visuelle. Si vous avez besoin d'une reproduction au pixel près de la mise en page d'origine (polices intégrées, positionnement exact, couleurs d'origine), tournez-vous vers des outils privilégiant la fidélité comme pdf2htmlEX, qui émet des éléments div positionnés en absolu correspondant visuellement au PDF source, mais produit un HTML pour ainsi dire illisible pour les lecteurs d'écran et rigide sur les écrans de téléphone.

Pourquoi mon PDF multicolonne ressort-il dans le désordre ?

Le PDF ne stocke pas l'ordre de lecture, seulement les positions. Un convertisseur doit déduire les limites des colonnes à partir de la distribution spatiale du texte. Pour les mises en page simples à deux colonnes, l'heuristique fonctionne généralement ; pour les mises en page complexes comportant des notes de marge, des notes de bas de page qui s'entrelacent avec le texte courant, ou du texte qui franchit une gouttière de colonne, elle peut produire une sortie dans le désordre. Si vous disposez d'un PDF balisé (un PDF qui inclut un arbre de structure), la précision est nettement meilleure ; pour les PDF non balisés, le résultat dépend de la netteté avec laquelle les colonnes sont physiquement séparées par des espaces blancs.

Mon PDF est numérisé (uniquement des images), pourquoi rien n'est-il extrait ?

Un PDF numérisé n'a aucun contenu textuel : chaque page est une image matricielle de texte plutôt que du texte que l'analyseur peut lire. Extraire le texte nécessite l'OCR (Tesseract, Google Cloud Vision, le framework Vision d'Apple, etc.), une opération fondamentalement différente de l'analyse d'un PDF. Cet outil n'intègre pas de moteur d'OCR, car les modèles sont trop volumineux pour être livrés avec un outil de navigateur. La bonne étape suivante est un service d'OCR dédié ou un outil de bureau doté d'un OCR intégré.

Puis-je convertir un PDF protégé par mot de passe ?

Si le PDF a un mot de passe d'ouverture (vous devez saisir un mot de passe rien que pour le consulter), PDF.js renverra une erreur au lieu de convertir. Si le PDF n'a qu'un mot de passe d'autorisations (l'ouverture est libre, mais l'impression et la copie sont restreintes), le comportement varie : la plupart des versions modernes de PDF.js respectent les autorisations et peuvent refuser d'extraire le texte. Dans les deux cas, la voie la plus propre consiste à retirer d'abord la protection dans l'outil PDF d'origine, puis à convertir. Retirer la protection d'un PDF que vous possédez légalement ne pose pas de problème ; le faire sur un PDF qui ne vous appartient pas peut en poser un.

Outils associés