Markdown ↔ HTML 双方向変換の使い方

1. 1テキストを入力またはペーストします
2. 2「変換する」ボタンをクリックします
3. 3結果を確認してコピーします

良いMarkdown ↔ HTML 双方向変換の判断基準

Markdownで書いた原稿をブログなどに貼るHTMLへ直すとき、逆に既存のHTMLを編集しやすいMarkdownへ直すときに使います。変換結果は、下の基準で「貼り付け先で意図どおり表示されるか」まで確認します。

• 貼り付け先で表示確認をしたか

  Markdownには方言（対応記法の差）があり、変換したHTMLの扱いも貼り付け先のサービスごとに異なります。手元の変換結果が正しくても、最終確認は必ず貼り付け先のプレビューで行います。

• 表などの拡張記法が変換されているか

  表（テーブル）や取り消し線は、元々のMarkdownには無い拡張記法です。使っている記法が変換結果に反映されているか、結果を見て確認します。

• HTMLからMarkdownへの変換で消えた要素はないか

  複雑なHTML（入れ子の構造・独自の装飾指定など）はMarkdownでは表現できず、変換で失われます。見出し・段落・リスト・リンクといった基本要素が残っているかを元と見比べます。

• 見出しの階層が保たれているか

  変換の前後で見出しのレベルが変わったり階層が飛んだりすると、貼り付け先の目次や見た目が崩れます。大見出し・中見出しの対応関係を見比べて確認します。

• リンクと画像のURLが生きているか

  変換でリンク先が欠落していないか、画像が手元のパソコン内のパス（そのままでは表示されない指定）になっていないかを確認します。

• 公開前の原稿を貼る前に所属組織のルールを確認したか

  公開前の原稿や社内文書には外に出せない情報が含まれることがあります。外部のツールに貼ってよいか、所属組織のルールを先に確認します。

ありがちな失敗例（NG → 改善）

Markdown で書いた原稿を CMS 用の HTML にするとき

ブログ執筆を Markdown で書いて CMS に貼り付けたい時、メルマガ HTML を Markdown 風に簡単編集したい時、GitHub の README を WordPress 用 HTML に変換したい時など、両形式を行き来する場面がよくあります。本ツールは双方向変換に対応し、Markdown → HTML の向きでは変換後の HTML プレビューも並ぶので、結果を即視覚確認できます。

処理はブラウザの中だけで完結します。編集部が3パターンを流しながら通信を見張った範囲では、処理中に生成 AI の API を呼ぶ通信は1件も発生しませんでした。

既存の markdown-preview / html-preview との違い

既存 markdown-preview: Markdown → HTML プレビュー表示のみ（変換結果のソースは取得しにくい） 既存 html-preview: HTML → プレビュー表示のみ 本ツール（markdown-html-converter）: Markdown → HTML / HTML → Markdown の「双方向変換」+ コピペ可能な変換結果ソース取得。3 つ併用で執筆フローを最適化できます。

もう1つ、同じ画面でも向きによって中の処理が別物です。Markdown → HTML は marked という変換ライブラリ、HTML → Markdown はタグを1つずつ置き換える自前の処理で動いています。この違いが結果にどう出るかは、後の項目で実際に確かめました。

ブログ執筆・README・メルマガで両形式を行き来する作業

【1. ブログ執筆 → CMS 投稿】Markdown で書き → HTML 変換 → WordPress / microCMS / Ghost に貼り付け。

【2. GitHub README → ドキュメントサイト】GitHub README.md を HTML 化 → 自社ドキュメントサイトに掲載。

【3. メルマガ HTML 作成】Markdown で本文書き → HTML 変換 → メール配信。

【4. 既存 HTML の編集を楽にしたい時】WordPress の HTML を Markdown 化 → 編集しやすい形にしてから本文修正 → HTML に戻す。

このうち4番目だけは、後の項目で示すとおり構造が崩れる条件があります。往復させる前に、崩れ方を知っておいた方が早く済みます。

見出し・リスト・引用・コードブロックを HTML にした実処理結果

既定のサンプルには、大見出しと中見出し、箇条書き3項目、引用、bash のコードブロック、外部リンクが入っています。これを Markdown → HTML にかけた結果を、出力欄の文字のまま記録します。

大見出しは <h1>無料 AI ツール集</h1>、中見出しは <h2>主要カテゴリ</h2> になりました。箇条書きは <ul> の中に <li> が3つ並び、各項目の先頭の強調は <strong> で囲まれています。引用は <blockquote> の中に <p> が入る形で、その中のリンクは <a href="https://free-ai-tools.jp/"> の形で残りました。コードブロックは <pre><code class="language-bash"> という、言語名がクラスに入った形に変換されています。

この向きの変換は広く使われているライブラリが担当していて、今回のサンプルでは崩れませんでした。画面の下には HTML プレビューが並び、変換直後の見た目をその場で確認できます。プレビューが並ぶのは Markdown → HTML の向きのときで、逆向きでは変換後の Markdown が出力欄に出ます。

script タグを書いた Markdown がそのまま HTML に出た実処理結果

危険なタグの無害化（サニタイズ）が入っているかを確かめました。1行目に見出し、そのあとに script タグの行、最後に本文の行を書いた Markdown を入れています。script の中身は alert を1回呼ぶだけの短いものです。

結果は、出力欄に <h1>テスト</h1> が出た次に、<script>alert(1)</script> がそのままの形で並びました。取り除かれてもいませんし、記号への置き換え（エスケープ）もされていません。画面下の HTML プレビュー領域にも、同じタグがそのまま差し込まれていました。ブラウザの仕様上、この差し込み方では script は実行されないため、今回のテストでも警告のダイアログは出ませんでした。

つまり本ツールは、Markdown の中に書かれた生の HTML を素通りさせます。自分で書いた原稿を変換する分には、意図した HTML をそのまま残せる利点になります。一方で、他人から受け取った Markdown を変換して、その結果を自分のサイトや配信メールに貼る使い方には向きません。貼った先では実行され得るためです。人から受け取ったテキストを通す場合は、貼り付け先の CMS 側のフィルタや、別の無害化処理を必ず挟んでください。

入れ子のリストを HTML から Markdown に戻したときの崩れ方

逆向きも試しました。親項目の下に子項目が2つぶら下がり、そのあとにもう1つ親項目が続く入れ子のリストを HTML で入れます。

返ってきた Markdown では、最初の親項目の行の直後に、1つ目の子項目がリスト記号を失った素の1行として続き、2つ目の子項目だけが記号付きの行になり、最後にもう1つの親項目が並びました。字下げによる親子関係は残っていません。

処理を追うと、入れ子の内側の項目タグが外側の項目タグの一部として飲み込まれるため、内側の記号が落ちます。表や入れ子の囲みタグは置き換えの対象になく、最後に残ったタグを一括で取り除く処理が走るので、中の文字だけが平らに残ります。

今回試した3パターンで見えた範囲での話で、どんな HTML でも同じ壊れ方をする保証ではありません。ただ、画面のヒントにも「HTML → Markdown は基本タグのみ対応（複雑な構造は手動調整推奨）」と書かれており、実測はその注意書きのとおりでした。

2つの向きで実装が違うことと、変換の限界

1つ目: HTML → Markdown 変換の限界 → 本ツールは基本タグ（h1-h4・p・ul/ol・li・strong・em・a・img・blockquote・code）のみ対応。table・div の入れ子・カスタム CSS class は失われます。複雑な HTML は手動調整推奨。

2つ目: Markdown 拡張記法 → 本ツールは CommonMark + GFM（GitHub Flavored Markdown）準拠。Notion / Obsidian 独自記法は対応外。

3つ目: HTML エンティティ → `&lt;` `&gt;` 等のエンティティは変換時に文字化けの可能性。大事な記号は手で確認してください。

4つ目: 改行の扱い → Markdown の「行末スペース 2 個 = 改行」は CMS によって解釈が異なる。コピペ後にプレビュー確認必須。

この4点は、実測でも同じ傾向でした。押さえておきたいのは、ライブラリが担当する Markdown → HTML は崩れにくく、タグの置き換えで動く HTML → Markdown は入れ子で崩れるという非対称です。原稿の正本をどちらの形式で持つかを決めるとき、この差は判断材料になります。

貼り付け先で確認する4点と、向かない用途

変換結果を CMS やメール配信に持っていく前に、人が見るのは4点です。1つ目は、見出しの階層が元の原稿と合っているか。2つ目は、リストの入れ子が残っているか（HTML から Markdown に戻した場合はここが落ちます）。3つ目は、意図しないタグが混ざっていないか。4つ目は、貼り付け先のプレビューでの改行の出方です。

向かない用途は3つあります。1つ目は、他人から受け取った Markdown や HTML を変換して、そのまま公開すること。生のタグが素通りします。2つ目は、表を含む HTML を Markdown に戻すこと。表は置き換えの対象になく、中の文字だけが平らに落ちます。3つ目は、装飾クラスを持つメールテンプレートの往復です。クラスは戻せません。原稿を Markdown で持ち、公開用の HTML は毎回そこから作る、という一方通行にすると、この3つの事故はまとめて避けられます。