HTML を Markdown にオンラインで無料で変換

オンラインで HTML ファイルを Markdown に無料で変換します。ファイルをアップロードすると、クリーンで LLM 対応の出力が即座に得られます。サインアップなし、ファイルあたり 50 MB、何も保存されません。

HTMLをMarkdownに変換する：保存したページを読める文書に戻す

Webから保存した.htmlファイルをテキストエディタで開くと、まず気づくのは記事本文がどれだけ少ないか ということです。ナビゲーションメニュー、Cookieバナー、トラッキングピクセル、インラインの<style> ブロック、6階層に入れ子になった<div class="wrapper-outer-container">——1500行のうち、 実際の文章はせいぜい40段落ほどです。これをそのままチャットアシスタントに貼れば、コンテキストウィンドウの大半を、 モデルにとって何の意味もないマークアップに使うことになります。

HTMLをMarkdownに変換すると、この比率がひっくり返ります。意味を持つタグは対応する記法に置き換わり、 見た目のためだけのタグは捨てられます。出てくるのは元のページと同じ形をした文書——見出し、リスト、表、リンク、 コードブロック——で、文字数はおよそ10分の1です。上でファイルをアップロードすれば数秒で手に入ります。 無料、登録不要、何も保存しません。

HTMLをMarkdownに変換したとき、タグはどう対応するか

MarkdownはもともとHTMLの一部を短く書くための記法として設計されたので、変換の大半はほぼ1対1の対応です。 対応関係を頭に入れておくと、出力に何が来るかを正確に予想できます。

  • <h1>から<h6>は#から ######になります。見出しの深さがそのまま保たれる点は、字面より重要です。 節ごとに要約させるとき、モデルはどの見出しが同じ階層なのかを知る必要があるからです。
  • <ul>、<ol>、入れ子になった<li>は、 ハイフンと番号のリストになり、入れ子はインデントで表現されます。
  • <table>は、それが本当にデータの表であればパイプ表になります。レイアウト目的の表—— メールのHTMLや古いサイトではまだ健在です——は、記法としては妥当でも意味のないものに変わります。
  • <a href>は[text](url)になるので、リンク先が残ります。アンカーテキストだけが 宙に浮くことはありません。
  • <code>と<pre>はバッククォートとフェンス付きブロックになります。 開発者がドキュメントページをこの形式に変換する最大の理由がこれで、スニペットがスニペットのまま残ります。
  • <strong>、<em>、<blockquote>は、 そのまま予想どおりの記法に対応します。
  • <script>、<style>、<meta>、インラインの style=属性、クラス名、data属性——すべて捨てられます。1つも残りませんし、残る必要もありません。

保存したページと、人が書いたHTMLは別物です

人が書いたHTMLファイルと、ブラウザが吐き出したHTMLファイルのあいだには実質的な差があり、それは出力に すぐ現れます。

手書きのHTML——静的サイトの書き出し、ドキュメントのビルド結果、メールテンプレート、レポートツールが生成した 帳票——はたいてい整理されていて、意味づけも素直です。見出しは見出し、段落は段落。この種のファイルは ほぼ完璧に変換されます。

一方、最近のサイトをCtrl+Sで保存したファイルはまったくの別物です。手に入るのはJavaScript実行後のDOMで、 固定ヘッダー、関連記事のレール、3つのニュースレター登録の誘い、リンクが80本並ぶフッターのサイトマップまで 一式ついてきます。どれも正当なHTMLですから、全部が変換されます。出力が間違っているわけではありません—— ページの調度品が混ざっているだけです。対処は2つ。ブラウザのリーダーモードで表示してからそれを保存するか、 先に変換してMarkdownの冒頭と末尾を削るかです。ざっと見て削る作業は1分もかかりませんし、その後の処理の質が 目に見えて変わります。

変換結果がほとんど空で返ってくるとき

保存したページを変換したら、タイトルと2行しか返ってこない。これは変換ツールの失敗ではなく、相手が シングルページアプリケーションだということです。

React、Vue、Angularといった系統で作られたサイトは、中身が文字どおり空のHTMLの殻を配信していることが よくあります。<div id="root"></div>とscriptタグだけ、という状態です。ブラウザで 見えていた内容は実行時にJavaScriptが組み立てたもので、ファイルの中には最初から存在しません。保存の仕方に よっては、描画結果ではなくこの殻のほうを捕まえてしまいます。テキストエディタでファイルを開き、読んだ覚えの ある一文を検索してみてください。見つからないなら、変換ツールにそれを作り出すことはできません。

対処は、描画後のDOMのほうを保存することです（Chrome DevToolsで<html>ノードを右クリックし、 outer HTMLをコピーして新しいファイルに貼り付けます）。あるいはファイルを経由せず、 Web2Txtを使うことです。こちらはURLを渡すと ページを正しく読み込んでMarkdownを返します。この違いは覚えておく価値があります。このページは すでに手元にあるHTMLファイルを変換し、Web2Txtは手元にないページを取りに行きます。

相対リンクという落とし穴

これはよく引っかかります。/docs/getting-startedや../api/reference.htmlへの リンクは、ブラウザがそのページのドメインとディレクトリを知っていることに依存しています。ファイルが サーバーから離れた時点で、その前提は消えます。変換後のMarkdownには [Getting Started](/docs/getting-started)が忠実に残りますが、このリンクはもうどこも 指していません。

LLMに読ませる用途なら、たいていは問題になりません。欲しいのは本文とリンクテキストであって、URLが解決するか どうかではないからです。ただし公開予定のドキュメントを作る場合や、相互参照が機能する必要のあるナレッジ ベースを作る場合は、出力を確認してパスを書き換えるか、リンクを外してください。画像のsrc属性も 事情は同じで、オフライン保存したページの画像が壊れた参照として出てくるのはこのためです。

HTMLファイルはMarkdownとプレーンテキストのどちらにすべきか

ページの構造そのものが必要なら、Markdownを選びます。コード例と見出し階層のあるドキュメント。番号付きの 手順があるチュートリアル。表を軸にした比較記事。セクションに分かれたメールマガジン。どれも #やパイプやフェンス付きブロックが実際の情報を運んでいて、LLM向けのHTMLから Markdownへの変換はまさにその情報を残すための処理です。

言葉だけが欲しいならHTMLをテキストに です。コーパスの構築、分類器への投入、検索インデックスの作成、そのほか構文用の記号がノイズにしかならない パイプライン全般がこれにあたります。ページ上部の形式切り替えは両者を行き来し、選択済みのファイルもそのまま 引き継ぐので、同じページを両方の形式に変換して見比べるのにアップロードは1回で済みます。

実際にどう使われているか

  • コーディングアシスタントにドキュメントを渡す。ライブラリのドキュメントページを保存して Markdownに変換し、GitHubリポジトリをテキストに 変換したものと並べて貼る。モデルはAPIの全体像と自分のコードでの使い方を同時に見られますし、 コードブロックは両側とも壊れずに残ります。
  • サイトの移行。静的サイトジェネレータはMarkdownを食べます。あとで手直しするとしても、 古いHTMLページの変換はCMS移行の最初の一手としてたいてい最速です。
  • 記事を保管して後で分析する。Markdownファイルは小さく、diffが取れて、grepできます。 保存したHTMLのフォルダでは決してそうはいきません。
  • メールテンプレートを読める内容に戻す。マーケティング用のHTMLはtable地獄で、 Markdown版のほうが本来のメッセージです。
  • プロンプトのライブラリを作る。Markdownの参考資料は、追加の加工なしにシステム プロンプトやRAGのインデックスへそのまま入ります。

ここで実用的なのは、出力の下にあるトークンカウンターです。ブラウザで見たときは短く思えたドキュメント ページも、表とコードブロックを含めると意外に重くなります。貼り付ける前に数字が分かるほうが、切り詰め エラーで気づくよりましです。

よくある質問

HTMLファイルをMarkdownに変換するには？

上で.htmlまたは.htmファイルをアップロードすると、Markdownになって返ってきます。.mdとしてダウンロードできます。無料、1ファイル50MBまで、アカウント不要。見出しは#のレベルに対応し、リストは入れ子のまま、リンクは[text](url)の形でURLを保ち、コードブロックはフェンス付きで残ります。

リンクとURLはそのまま残りますか？

残ります。ここでプレーンテキストではなくMarkdownを選ぶ主な理由がこれです。すべてのアンカーが[label](href)に変換されるので、リンク先が生き残ります。ドキュメントを保管する場合や、ページがどこを指しているかを点検する場合、これは使える記録と単なる言い換えの差になります。

保存したファイルではなく、URLを直接変換できますか？

このページからはできません。Web2TxtならURLを渡すだけでページを取得し、Markdownを返します。このページの担当は、すでにディスク上にあるHTML——保存した記事、書き出したニュースレター、生成されたレポート、ローカルビルドの出力——です。

静的サイトジェネレータへの移行手段として妥当ですか？

本文に関しては妥当です。散文、見出し、リスト、表、コードブロックは、そのままコミットして手を入れられる程度にはきれいに変換されます。できないのは、情報設計の作り直し、内部リンクの新しいパスへの書き換え、フロントマターの抽出です。この3つは、どの変換ツールを使っても手作業のまま残ります。

表とコードブロックはどうなりますか？

表はパイプ表になり、フェンス付きコードブロックはフェンス付きのまま残ります。どちらも元のHTMLで明示的にマークアップされているので、たいていうまく生き延びます。よく犠牲になるのは、トークンごとの<span>クラスで表現されたシンタックスハイライトです。コード自体は正しいものの、色付けの元になっていた言語の指定は復元できないことが多いので、必要なら手で書き足してください。

ほかの形式とツール

HTMLはFile2Txtが扱う形式の1つです。 何をアップロードしても適切に処理します。中身が分かっているなら、 PDFをMarkdownに変換、 WordをMarkdownに、 JSONをMarkdownに、 XMLをMarkdownにへ直接どうぞ。 表形式の書き出しなら、CSVをMarkdownに が区切りデータからパイプ表を組み立てます。

コードが相手なら、GitHubリポジトリをテキストに、 GitLabプロジェクト、そして何も アップロードしないローカルフォルダ変換が あります。HTML固有の話ではなく一般論が読みたければ、 LLM向けに文書を整える方法のガイド という長めの記事もあります。

Repo2Txtを開発・運営しているのは v12hero、 プライバシー最優先のネイティブアプリとWebアプリを作る独立系デベロッパーです。