無料 PDF → HTML コンバーター
PDFドキュメントからテキストを抽出し、クリーンなセマンティックHTMLに変換します。瞬時にプレビューして、コードをダウンロードまたはコピーします。
処理中…
PDF → HTML変換について
このツールはPDF.jsを使ってPDFファイルからテキストを抽出し、それをセマンティックHTMLとしてレンダリングします。ドキュメントをWeb互換形式に変換、コンテンツをアーカイブ、またはさらなる処理のためにテキストを準備するのに最適です。
一般的な用途
- ドキュメントアーカイブ · 長期的なデジタル保存とWebアクセスのためにPDFをHTMLに変換します。
- コンテンツ移行 · CMSまたはWebパブリッシング用にPDFから構造化HTMLにテキストを抽出します。
- テキスト抽出 · 分析または再利用のためにPDFからクリーンなテキストを取得します。
- Webパブリッシング · ドキュメントを高速読み込みとアクセシビリティの向上のためにWeb互換形式に変換します。
- データ処理 · さらなる変換または統合のためにPDFコンテンツを準備します。
よくある質問
どのPDFサイズがサポートされていますか?
このツールは、ブラウザに応じて約10 MBまでのPDFを処理できます。非常に大きいまたは複雑なPDFは処理により時間がかかる場合があります。
PDFのフォーマットを保持しますか?
ツールはテキストコンテンツを抽出し、段落でレンダリングします。複雑なレイアウト、画像、スタイルはクリーンなHTMLに簡素化されます。
HTMLをダウンロードできますか?
はい。「HTMLをダウンロード」をクリックして、変換されたコンテンツを.htmlファイルとして保存します。任意のブラウザまたはエディターで開けます。
PDF小史：PostScriptから持ち運べるページへ
PDFはAdobe Systemsの共同創業者ジョン・ワーノックの構想によるものです。ワーノックは以前、1985年のApple LaserWriterから始まりDTPを可能にしたページ記述言語PostScriptを共同発明していました。PostScriptは極めて強力でしたが、プログラミング言語であり、文書フォーマットではありませんでした。PostScriptファイルはインタープリターに渡せばページのレンダリング方法を記述できましたが、適切なフォントのない異なるマシン間で一貫して読み取り・編集・表示できるよう設計されていませんでした。
1991年、ワーノックはAdobe社内メモを配布しました。これが後にキャメロット・プロジェクトとして知られるようになります。その前提はこうでした。Adobeはフォント・レイアウト・ベクターグラフィックス・画像を含むあらゆる文書をキャプチャし、どのコンピューターでも、どのOSでも、最初に作成したアプリケーションに関係なく同一に再現できる、単一のファイルフォーマットを構築すべきだというものです。提案が洗練される頃にはプロジェクトに製品名が付きました。Adobe Acrobatです。
Acrobat 1.0とPDF 1.0は1992年11月にラスベガスで開催されたComdex Fallトレードショーでデモが行われ、1993年6月に顧客へ出荷されました。Adobeの重要な商業的決断は1994年に訪れ、Acrobat Readerを無償配布し始めました。これはHTMLブラウザで起きたことを鏡写しにし、数百万のインストール基盤を築きました。フォーマットはその後いくつかの改版を経ました。PDF 1.1（1996年、外部リンクとセキュリティ）、1.2（1996年、AcroForms）、1.3（2000年、デジタル署名）、1.4（2001年、透過）、1.5（2003年、オブジェクトストリームとJPEG 2000）、1.6（2004年、OpenTypeと3D）、1.7（2006年）。2008年にPDF 1.7はISO 32000-1:2008として公開され、PDF 2.0はISO 32000-2:2017として続き、実質的な改訂を経た第2版（ISO 32000-2:2020）が現在の権威ある参照規格となっています。
メイン規格と並んでいくつかの特化PDFプロファイルが存在します。PDF/A（ISO 19005-1:2005、-2は2011年、-3は2012年）は外部リソースや将来のソフトウェアに依存する機能を禁止するアーカイブプロファイルです（JavaScriptなし・音声なし・暗号化なし・フォントは埋め込み必須）。PDF/Xは印刷業界が使用するプレプレスプロファイルです。PDF/Eは技術図面向けのエンジニアリングプロファイルです。PDF/UA（ISO 14289-1:2014）はスクリーンリーダーが読み取り順にコンテンツを提示できるよう論理構造とタグ付けを要求するユニバーサルアクセシビリティプロファイルです。PDF/VTはパーソナライズドメール差し込みに使用される可変・トランザクションプロファイルです。
PDFからHTMLへの変換が構造的に難しい理由
PDFは最低レベルでは番号付きオブジェクト（辞書・配列・文字列・数値・名前・バイナリストリーム）の集合であり、ファイル全体を解析せずに任意のオブジェクトへジャンプできるよう末尾にクロスリファレンステーブルを持ちます。オブジェクトはCatalogオブジェクトをルートとするツリーを形成し、そこからPagesツリーへ、そしてPageオブジェクトへとつながります。各ページはページを描画する実際の命令群であるコンテンツストリームを参照します。
コンテンツストリームはPostScriptに関連するがチューリング完全ではない小さな言語のコンパクトなグラフィカル演算子の列です。テキストについては、Tf（フォントとサイズの設定）、Td（テキスト位置の移動）、Tm（テキスト行列の設定）、Tj（文字列の表示）、TJ（カーニング用のオプション個別文字オフセット付き文字列配列の表示）、ET（テキスト終了）を使用します。重要なのは、すべてが位置指定であるという点です。本文の段落は段落として保存されているわけではありません。ページ上の特定のx座標とy座標でグリフまたは短いグリフの連続を描画する、一連のTjまたはTJコマンドとして保存されています。文・段落・見出し・リスト・カラムという概念はなく、あるのは各文字が物理的にどこに位置するかという問いだけです。
HTMLはその逆です。セマンティックな要素の流動的なツリーであり、レイアウトはレンダラーの責任であるため、同じHTMLがスマートフォン・デスクトップ・スクリーンリーダーに合わせてリフローできます。PDFからHTMLへの変換には、PDFが記録する必要のなかった構造をリバースエンジニアリングする必要があります。コンバーターは各ページのテキストの空間分布を見て次のことを推定しなければなりません：
- フォントの平均アドバンス幅に対してグリフ間の間隔を測定することで、どの文字が同じ単語に属するか。
- 許容範囲内でy座標をクラスタリングすることで、どの単語が同じ行に属するか。
- ベースラインの差とインデントパターンを検出することで、どの行が同じ段落に属するか。
- 縦方向の空白ガターを見つけることで、どの段落が同じカラムに属するか。
- そして複数カラム・脚注・サイドノートにわたる読み取り順序。
これらはコンテンツストリームを順番に読むだけでは解決できません。ストリーム内の順序は必ずしも読み取り順序ではないからです。PDFを生成したレイアウトエンジンは、レンダリングに最も効率的な順序で要素を描画した可能性があり、それはジグザグの上から下の順序だったり、フォント別だったり、色別だったりします。一つの段落のテキストが、基底ストリーム内で隣接する段落のテキストと交互に並んでいることもあります。単純にストリーム順に文字列を連結するだけのPDF抽出器が、単一カラムの小説より複雑なものに対して文字化けした出力を生成するのはこのためです。
PDFがタグ付きである場合、つまり著者が視覚的なコンテンツと並行して構造ツリーを含めた場合、作業は大幅に容易になります。タグ付きPDFにはHTMLのセマンティック語彙を反映した構造要素の階層（段落のP、見出しのH1〜H6、リストのL、リスト項目のLI、Table・TR・TD・Figure・Caption）が含まれます。PDF/UAは、タグなしPDFが支援技術には本質的に不透明であるため、アクセシビリティのためにタグ付けを義務付けています。しかし実際には、世の中に出回っているPDFの大多数はタグなし、またはオーサリングツールによるタグ付けが不完全であり、堅牢なコンバーターはタグが存在する場合でもレイアウト解析にフォールバックする必要があります。
主要なオープンソースPDFレンダリングライブラリ
PDF.jsはMozillaが開発したJavaScriptライブラリで、Andreas Galが主導した実験的プロジェクトとして2011年6月にローンチされました。ネイティブプラグイン不要で、HTML5 canvasとJavaScriptだけでブラウザ内でPDFを解析・レンダリングします。PDF.jsはAdobe Readerプラグインを置き換える形で、2013年3月のFirefox 19からデフォルトのPDFビューアとしてFirefoxに同梱されました。位置メタデータ付きのテキストコンテンツ（各テキストランのx・y・幅・高さ・フォント名・フォントサイズ）を抽出できるJavaScript APIを公開しています。このツールはPDF.jsを基盤としています。
Popplerは1990年代後半からGlyph and Cogがメンテナンスしている老舗PDFビューアxpdfからフォークされたC++ライブラリです。LinuxデスクトップのPDFレンダリング機能（GNOMEのEvince・KDEのOkular）、コマンドラインユーティリティのpdftotextとpdftohtml、多くのサーバーサイドPDF処理パイプラインを担っています。MuPDFはArtifex Software（Ghostscriptを管理する同じ会社）が開発した、組み込み用途向けの小型・高速Cライブラリです。PDFiumはGoogle ChromeとMicrosoft Edgeに組み込まれたPDFビューア用エンジンで、GoogleとFoxitが2015年5月に共同オープンソース化したFoxit PDF SDKのフォークです。qpdfはレンダリングではなく構造的な操作に特化したC++ライブラリとコマンドラインツールで、視覚的なコンテンツを変えずにPDFを展開・暗号化・復号・線形化・再書き込みできます。
HTML出力に特化した中で最も重要なプロジェクトはpdf2htmlEXで、もともとLu Wangが2012年に開発し、現在はコミュニティグループがメンテナンスしています。pdf2htmlEXは多くのコンバーターとは異なるアプローチを取ります。セマンティックHTMLを再構築しようとするのではなく、各テキストランに絶対位置指定のdiv要素を出力し、元のフォントをWeb Open Font Format（WOFF）ファイルとして埋め込み、必要に応じてCSSトランスフォームを使用することで、PDFの視覚的レイアウトをできる限り忠実に再現します。結果として生成されるウェブページは元のPDFと見分けがつきませんが、基礎となるHTMLはposition: absoluteスパンの壁であり、セマンティックな意味を持ちません。
レイアウト忠実度とセマンティックな流れ：中心的なトレードオフ
これがPDF-HTML変換における中心的なトレードオフです。レイアウト忠実度を取るか、セマンティックな流れを取るか。両方を兼ね備えることは困難です。pdf2htmlEXのような忠実度優先のコンバーターは元のものと同様に印刷・表示できる出力を生成しますが、スクリーンリーダーには不透明でスマートフォン画面では硬直しています。pdftotextやPDF.jsのgetTextContentに続くシンプルな段落再構築のような流れ優先のコンバーターは、クリーンで読みやすくアクセシブルなHTMLを生成しますが、元の視覚的な豊かさ（色・正確なフォント・画像配置・テーブルのグリッド・元のページの感覚）を失います。
Absolutoolのツールは明確に流れ優先の側にあります。PDF.jsを使用してテキストコンテンツを抽出し、ピクセルパーフェクトな再現よりも可読性・アクセシビリティ・小さなファイルサイズを優先して段落として出力します。視覚的再現ルート（すべてのグリフをオリジナルの位置に、フォントを埋め込み、正確なページ付けを保持）が必要な場合はpdf2htmlEXを検討してください。読みやすい段落ルート（コンテンツの再利用・ウェブ公開・検索インデックス可能なHTML・スクリーンリーダーアクセシブルな出力）が目的であれば、このツールが適しています。
埋め込みフォント・画像・その下にあるベクターコンテンツ
PDFには任意のフォントを埋め込めますが、元の外観を保持しようとするコンバーターには3つの選択肢があります。埋め込んで配信：コンバーターはPDFから各埋め込みフォントを抽出し、ブラウザが理解するウェブフォント形式（WOFFまたは2018年以降はより積極的なBrotli圧縮を使用するWOFF2）に再パッケージし、生成されたHTMLからリンクします。元の外観は保持されますが、フォントの埋め込み権限がウェブ再配布にまで及ばない場合、ファイルサイズが膨らみライセンス問題が生じる可能性があります。代替：各埋め込みフォントを近似のシステムフォント（セリフPDFフォントはTimes New RomanやGeorgiaになる場合がある）にマッピングし、視覚的なズレを受け入れる代わりに小さくクリーンな出力を得ます。無視：フォント情報を完全に破棄し、ブラウザにデフォルトの本文フォントを適用させます。これは多くの流れ優先コンバーターが採用する選択で、ユーザーがブラウザの通常のスタイリングでHTMLを読むためです。
画像も同様の選択を迫られます。コンバーターは埋め込み画像を別ファイルとして抽出してHTMLから参照することも、ページ全体を画像としてラスタライズしてインラインで埋め込む（PDFを豪華なギャラリーに変える）ことも、画像を完全に削除してテキストのみを出力することもできます。後者はコンテンツの再利用に適した、このツールが採用するアプローチです。ベクターコンテンツ（PDFのグラフィックス演算子が描画する線・形・パス）はさらに厄介で、セマンティックHTMLで表現するクリーンな方法がないため、保持しようとするコンバーターはインラインSVGまたはPNGラスタライズにフォールバックする傾向があります。
PDFが画像の場合：スキャンされた文書へのOCRフォールバック
世の中に出回っているPDFのうちかなりの割合は、構造的な意味での文書ではまったくなく、PDFがインターネットで紙のようなものを送るためのユニバーサルフォーマットであるためPDFでパッケージされた紙文書のスキャン画像です。スキャンされたPDFにはテキストコンテンツストリームがありません。各ページはテキストを描写しているがマシンが読み取れる文字として含んでいない単一の埋め込みラスター画像です。このようなPDFからテキストを抽出するには光学文字認識（OCR）が必要で、これはテキスト抽出とは根本的に異なる操作です。
主要なオープンソースOCRエンジンはTesseractで、もともと1985年から1995年にかけてHP Labsで開発され、2005年にオープンソース化し、2006年からGoogleがメンテナンスし、2018年頃にGoogleがコミュニティグループに主要管理権を引き渡しました。100以上の言語をサポートし、あらゆる主要プラットフォームで動作し、数多くのデスクトップおよびサーバーツールのOCR機能を担っています。2017年からmacOSとiOSで利用可能なAppleのVision frameworkには、OSの組み込みスクリーンショットおよび写真アプリが使用する高速・高精度のテキスト認識APIが含まれています。Google Cloud Vision・Azure Computer Vision・Amazon Textractが主要なクラウドOCRサービスです。文書向けとしては、TextractとAzureのDocument Intelligenceはいずれも生のOCRを超えて、テーブル・キーと値のペア・フォームフィールドを認識します。
完全にクライアントサイドで動作するブラウザベースのPDF-HTMLコンバーターは一般にOCRを実行できません。OCRモデルは最小でも数十メガバイトあり、推論処理はユーザーのノートPCで対話的に実行するには遅すぎます。PDFに抽出可能なテキストのないスキャンページが含まれている場合、このツールはそれらのページで空の出力を生成します。次の適切なステップは別のOCRツールかサーバーサイドサービスです。
PDFをHTMLに変換する理由
ユースケースはいくつかの繰り返し現れるパターンに分類されます：
- レガシーレポートのアーカイブを持つ出版社：年次報告書・ホワイトペーパー・研究論文・政府刊行物・技術マニュアルをHTMLに変換することで、ファイルのダウンロードを強いることなくブラウザで直接コンテンツを読めるようにします。HTMLバージョンはナビゲートしやすく（特定のセクションにリンク可能）、スマートフォンでの読み込みが速く、検索エンジンにクロール可能です。
- ブロガーやコンテンツマーケターは、自身が執筆またはライセンスを取得したPDFをHTMLに変換し、テキストを入力し直すことなくコンテンツを記事として再利用します。
- ウェブアーキビストは、仕様が数千ページに及ぶ複雑なバイナリフォーマットよりもHTMLの方が数十年にわたって耐久性があるという考えのもと、保存プロジェクトの一環としてPDFをHTMLに変換します。
- モバイル読書アプリや後読みサービスはPDFをHTMLに変換し、ユーザーが好みのフォントとフォントサイズ・ダークモード・調整可能な行長でリーダービューで記事を開けるようにします。
- スクリーンリーダーユーザーは、タグなしPDFが支援技術には本質的に不透明であるためPDFをHTMLに変換します。適切な段落と見出しを持つHTMLレンダリングは音読がきれいにできます。
- ナレッジマネジメントのワークフローでは、検索インデックス・全文データベース・大規模言語モデルのコンテキストウィンドウにコンテンツを供給するためにPDFをHTMLに変換します。これらはいずれもネイティブにPDFフォーマットを理解しませんが、プレーンテキストとHTMLはうまく処理できます。
- 研究者や学術関係者は、引用管理ツール・参考文献データベース・数千の論文にわたるパターンを探すテキストマイニングパイプラインに供給するため、学術論文PDFからテキストを抽出します。
それぞれのユースケースには若干異なる要件がありますが、共通するのは：ユーザーは元の文書が選んだ固定的なページバインド形式に縛られることなく、PDFのコンテンツ（言葉・構造・意味）を必要としているという点です。
よくある質問
変換したHTMLが元のPDFと異なるのはなぜですか？
このツールは流れ優先です。テキストを抽出し、視覚的な忠実度よりも可読性・アクセシビリティ・検索インデックス可能性を優先してブラウザのデフォルトフォントでクリーンな段落を出力します。元のレイアウトのピクセルパーフェクトな再現（埋め込みフォント・正確な位置・元の色）が必要な場合は、ソースPDFを視覚的に一致させるが本質的にスクリーンリーダーが読めずスマートフォンで硬直した絶対位置指定div要素を出力する、pdf2htmlEXのような忠実度優先ツールを検討してください。
複数カラムのPDFが文字化けして出力されるのはなぜですか？
PDFは読み取り順序ではなく位置のみを保存します。コンバーターはテキストの空間分布からカラム境界を推定する必要があります。シンプルな2カラムレイアウトではヒューリスティックは通常機能しますが、サイドノートがある複雑なレイアウト、本文テキストと交互に並ぶ脚注、カラムガターをまたぐテキストでは順序が入れ替わった出力が生じることがあります。タグ付きPDF（構造ツリーを含むもの）であれば精度は劇的に向上します。タグなしPDFの場合、結果はカラムが空白でどれだけ明確に分離されているかによります。
PDFがスキャン（画像のみ）の場合、何も抽出されないのはなぜですか？
スキャンされたPDFにはテキストコンテンツがなく、各ページはパーサーが読み取れるテキストではなくテキストのラスター画像です。テキストの抽出にはOCR（Tesseract・Google Cloud Vision・AppleのVision frameworkなど）が必要で、これはPDF解析とは根本的に異なる操作です。このツールはOCRエンジンをバンドルしていません。モデルがブラウザツールに同梱するには大きすぎるためです。次の適切なステップはOCR専用サービスか、OCRを内蔵したデスクトップツールです。
パスワード保護されたPDFを変換できますか？
PDFにオープンパスワード（表示するだけでもパスワードが必要）が設定されている場合、PDF.jsは変換せずにエラーをスローします。PDFにパーミッションパスワードのみ（表示は自由だが印刷・コピーが制限）が設定されている場合、動作はさまざまです。最近のPDF.jsのビルドの多くはパーミッションを尊重し、テキスト抽出を拒否する場合があります。いずれにせよ最もクリーンな方法は、最初に元のPDFツールで保護を解除してから変換することです。合法的に所有するPDFの保護を解除することは問題ありません。所有していないPDFで行うことは問題となる場合があります。