同僚が Slack に貼った関数のレビュー
誰かが2つのコードブロックをチャットに投げて、どちらが正しいか聞いてくる。20行のスニペットのためにリポジトリを clone し、ブランチを切り替え、IDE を開くのは無駄な労力です。両方を diff ツールに貼れば、次のメッセージが届く前に答えが出ます。オンライン diff を使う最も多い理由がこれです。
元 (バージョン A)
変更後 (バージョン B)
Git Diff Online: ブラウザで2つのコードバージョンを比較
左にバージョン A、右にバージョン B を貼り付けると、何が変わったかを正確に表示します。git clone も IDE も登録も不要。すべてブラウザ内で動作します。
このオンライン git diff ツールについて
Git、GitHub、IDE を開かずに2つのコードバージョンを比較するための、ブラウザ内で動作する無料ツールです。古いバージョンを左に、新しいバージョンを右に貼り付けると、文字単位で差分がハイライトされます。テキストはマシンから一切送信されないため、private repo や未マージのブランチからのスニペットでも安心です。
同僚が Slack に2つのバージョンの関数を投げて「何が変わった？」と聞いてくる、その瞬間のために作られています。12行の diff のためにローカル checkout を立ち上げるのはやり過ぎです。PR がまだない段階で GitHub の PR ビューを開くのも同様。テキストペイン2つ、diff 1つ、15秒で完了です。
実際の working tree 上での git diff の代替ではありません。hunk のステージング、patch の適用、blame の実行はできません。できるのは、最も頻繁に必要となる部分です。任意の2つのテキストブロックを取り、その間の編集を表示することです。内部的には、diff そのものは compare-text ツールと同じエンジンを使い、code review 向けに整えています。
diff の内部の仕組み
diff は文字単位で実行され、その後セマンティッククリーンアップのパスが変更を読みやすいかたまりにグループ化します。これにより、ハイライトはリネームされた識別子の単位で表示され、その中の各文字単位ではなくなります。右ペインの挿入は緑、左ペインの削除は赤で表示されます。2つのペインはスクロールが連動するため、片方の80行目で変更を見つければ、もう片方も一緒にジャンプします。
なぜ行単位ではなく文字単位なのか。短いスニペットでは、行のみのビューは粗すぎるからです。変数を id から userId にリネームするのは、識別子の1つの変更です。行単位の diff だと、行全体を削除済み、新しい行を挿入済みとして表示します。技術的には正しいですが、実際の編集箇所は見つけにくくなります。文字モード+セマンティッククリーンアップは、リネームされたトークンだけをハイライトし、行の他の部分はそのままにします。長いファイルではトレードオフが反対になり、Git がデフォルトで 古典的な行ベースの diff を使うのはそのためです。両者にそれぞれの居場所があります。このツールはスニペット向けのビューを提供します。
このツールが意図的にやらないこと。シンタックスを認識しません。JavaScript、Python、Java をパースしません。同じ意味で再フォーマットされたブロックも diff として表示されます。テキスト比較器にとっては別のテキストだからです。構造化ペイロードに対するフォーマット認識 diff が必要なら、compare-json ページが JSON を、compare-yaml が YAML を、compare-xml が XML と POM ファイルを処理します。生のソースコードについては、テキスト diff と自分の目で読むほうが、単発の用途のためにシンタックス認識ツールを設定するより速いことが多いです。
コードを diff する3つのステップ
テキストペイン2つ、diff 1つ。ログインも、アップロードも、パースすべき patch フォーマットもありません。
- 1
左にバージョン A を貼り付け
エディタ、ターミナル、その他どこからでも、関数、ファイル、スニペットの古いバージョンをコピーします。Ctrl+C で左ペインに貼り付け。
git show <commit>から取り出している場合は、patch ヘッダーではなくファイル本体をコピーすると、diff は実際のコード変更だけをハイライトします。 - 2
右にバージョン B を貼り付け
新しいバージョンも同様に。同僚が Slack、Teams、メールに貼っていた場合は、そこから直接コピーしてください。空白とインデントは貼り付け時に保持されます。Python や YAML のようにインデントが意味を持つ言語では重要です。タブとスペースが食い違っていれば、差分として表示されます。
- 3
ハイライトされた差分を確認
削除は左に赤い取り消し線で、挿入は右に緑で表示されます。各ヘッダーの変更カウンタは検出された個別の編集数を示します。ハイライトを読み、まずロジック変更（制御フロー、条件分岐、エラーハンドリング）に注目し、純粋なリネームやフォーマット変更はレビュー時の優先度を低めに扱ってください。
オンラインコード diff が向いている場面
ビルドスクリプトの2つのバージョンを比較
CI パイプライン、Dockerfile、package.json、GitHub Actions ワークフロー YAML は常に変化します。チームメイトがブランチで .github/workflows/ci.yml を編集してビルドが壊れた、彼のブランチを checkout せずに何が変わったか確認したい。main 版と壊れたブランチ版を並べて貼れば、原因のステップは大抵数秒で浮かび上がります。ワークフローファイル特有のインデント周りのエッジケースは、私たちの YAML diff ページがよりきれいに扱います。
非エンジニアに PR の変更点を見せる
プロダクトマネージャー、デザイナー、アカウントマネージャーは、Git のインターフェースを読まずにコード変更の内容を知りたいことがあります。GitHub の PR ビューは diff のシンタックス、ファイルツリー、レビューコメントへの慣れを前提にします。前後をきれいな2ペインビューに貼り、一緒にハイライトを追えば、はるかに親切です。インシデントのポストモーテムでエンジニアリング外の人を含む場合にも有効です。
2つのコミットの git show 出力を比較
あるファイルについて2つのコミットでの git show abc123 と git show def456 の出力がある。CI ログやリモートサンドボックスから取得していて、git コマンドを簡単には実行できない。patch ヘッダーを取り除き、2つのファイル内容を貼って diff します。サーバー上でデバッグしているとき、ビルド成果物を読むとき、特定の2つのコミットからファイル内容を引用するセキュリティアドバイザリをレビューするときに有効です。
メールや PDF からのコードをレビュー
ベンダーが PDF でサンプル統合を送ってくる。規制当局がポリシーコードのスニペットをメールしてくる。コンサルタントがスクリプトのパッチ版を添付してくる。どれも clone 可能なリポジトリではありません。PDF やメールからテキストをコピーし、現在のバージョンの隣に貼れば、1分以内に使えるレビュー画面が手に入ります。PDF からのコピペは多少の整形ノイズを伴います。改行と引用符が常連の犯人です。
知っておく価値のあるコード diff のエッジケース
平文テキスト diff が Git や IDE、code review ツールが示す結果と食い違うケース。本番コードを貼って偽陽性を心配する前に、目を通しておく価値があります。
| Topic | What this tool does |
|---|---|
| 改行コード（CRLF と LF） | Windows 形式の CRLF と Unix 形式の LF は別のバイトです。Windows のエディタから貼ったファイルと Linux コンテナから貼ったファイルは、見た目のテキストが同一でも、改行コードが異なればファイル全体の diff として表示されます。Git は core.autocrlf で正規化しますが、このツールはしません。 |
| 行末の空白 | 行末のスペースやタブは差分として表示されます。Git の core.whitespace はコミット時に警告や自動修正ができますが、ここでは貼ったものがそのまま比較対象です。code review のノイズフロアが行末空白の編集だらけなら、diff の前にエディタで取り除いてください。 |
| バイナリファイル | このツールはテキスト専用です。バイナリファイル（PNG、コンパイル済み JAR、sqlite DB）の中身を貼ると意味不明な出力になるか、タブが固まります。バイナリ diff については、Git は patch ではなく "Binary files differ" と表示します。実際の内容にはフォーマット固有のツールが必要です。 |
| .gitattributes のテキスト/バイナリ指定 | リポジトリの .gitattributes は、ファイルパターンごとに Git のテキスト/バイナリ判定を上書きできます。その設定はコピペでは引き継がれません。あるファイルが2つの checkout で異なる扱いを受けている疑いがあれば、そのファイルを見るべきです。このツールはいずれにせよ平文テキストとして diff します。 |
| 文字単位 vs 行単位の diff | このページは文字レベルの diff にセマンティッククリーンアップを加えています。Git はデフォルトで行単位、オプションで git diff --word-diff による単語単位です。文字単位は単一トークンが変わった短いスニペットに、行単位は多くの行がまとめて変わった長いファイルに最適です。 |
| git diff --word-diff | Git の --word-diff モードは行内の単語レベルの変更を強調し、スニペットに対するこのツールの動きに近いです。出力フォーマットは異なります（ターミナル向けのマークアップと side-by-side ペイン）が、目的は重なります。ターミナル中心の人にとっては --word-diff がローカルでの相当機能です。 |
| 大きなファイルのしきい値 | ブラウザベースの diff は片側数千行までは反応良く動きます。それを超えると、セマンティッククリーンアップが遅くなり、レンダリングされた DOM が重くなります。巨大なファイルではローカルで git diff を実行して pager に流すか、比較を小さなセクションに分けてください。 |
| エンコーディング（UTF-8 のみ） | diff は UTF-8 入力を前提とします。2026年時点でほぼすべてのソースコードがこれに該当します。UTF-16、Windows-1252、Shift-JIS で保存されたファイルは、ブラウザによっては貼り付け時に文字化けする可能性があります。スニペットが乱れて見える場合は、ソースファイルを UTF-8 で再保存してからコピーしてください。 |
オンライン git diff: よくある質問
ローカルで git diff を実行するのと何が違いますか？
ローカルの git diff は、実際のリポジトリ内で2つの ref（commit、ブランチ、working tree）を比較します。インデックス、worktree、履歴を知っています。このオンラインツールはそうした処理は一切しません。貼り付けた任意の2つのテキストブロックを比較します。checkout したリポジトリでの本格的なレビュー作業には git diff を使ってください。2つのスニペットがあって working tree に持ち込む手段がない場合、あるいはコンテキストを切り替えずに side-by-side ビューが欲しい場合に、これを使ってください。
GitHub や GitLab が PR で表示するのと一致しますか？
完全には一致しません。GitHub や GitLab はファイルコンテキスト、hunk ヘッダー、ファイルごとの要約を伴う行ベースの unified diff を使います。このツールは文字レベルの diff にセマンティッククリーンアップを加えたものを使い、短いスニペットには向き、変更の多いファイル全体には向きません。本格的なプルリクエストレビューは GitHub の PR ビューで行ってください。PR の外で素早くスニペット比較したい場合は、こちらが速く、目的のリポジトリへ移動する必要もありません。
JavaScript や Python などのシンタックスを理解しますか？
いいえ。これは平文テキストの diff です。言語をパースしないため、リネームされた変数が12箇所で同じ識別子であることを認識できず、シンタックス認識 diff のように再フォーマットされた空白を無視することもできません。スニペットレビューの大半では、ハイライトを自分の頭で読むので問題ありません。コードの真のセマンティック diff が必要なら、IDE（VS Code、IntelliJ）や tree-sitter ベースの diff が適切なツールです。このページは速度を最適化しており、深いパースは目的としていません。
unified フォーマットの diff -u と比べてどうですか？
古典的な Unix コマンド diff -u は unified フォーマットの patch を生成します（Git が内部で使うのと同じフォーマット）。行ベースで、機械可読を狙って設計されているため、patch を別の場所に適用できます。このツールは人間向けです。プラスとマイナスの行が並んだ1列ではなく、インライン強調を備えた2つの side-by-side ペインを表示します。git apply や patch -p1 で適用できる patch ファイルは生成しません。patch を生成したいならコマンドラインを使ってください。diff を読みたいなら、こちらのほうが親切です。
改行コードや行末空白は扱えますか？
はい、ただし独自のやり方で。CRLF（Windows）と LF（Unix）の改行コードは、貼り付けた2つのスニペットで食い違っていれば差分として表示されます。技術的には別のバイトだからです。行末の空白も同様。これは core.autocrlf がオフのときに Git がファイルを扱う動きと一致します。空白ではなくロジック変更だけが気になる場合は、貼り付け前に各ペインを trim してください。「空白を無視」のトグルは現時点では用意していません。ロードマップには入っています。git diff -w がローカルでの相当機能です。
サイズ制限はありますか？
事実上あります。diff はブラウザ内で動作するため、非常に大きな入力（vendor された丸ごとのライブラリや 50,000 行の生成ファイルなど）は、ブラウザのメモリに応じてページを遅くしたりタブを停止させたりします。一般的な code review 作業（関数、ファイル、ビルドスクリプト、片側数千行までの設定）であれば、diff はほぼ瞬時に終わります。リポジトリ全体を比較するなら、本物の Git ツールやフォルダ比較ツールが正解です。このページはスニペットや単一ファイル向けに作られています。
プライバシーと仕組み
コードはブラウザから一切出ません。diff、ハイライト、レンダリングはすべてマシン上で動作します。テキストをアップロードすることも、ログを取ることも、第三者サービスに渡すこともありません。これはプロプライエタリなコードレビューにおいて特に重要です。未公開の機能、セキュリティパッチ、private repo のスニペットをクラウドサービスに貼ること自体が、雇用主のデータ取り扱いポリシー違反になりうるからです。この主張の検証は簡単です。ブラウザの DevTools を開き、Network タブに切り替えて、両方のバージョンを貼って眺めるだけ。比較時に外向きのリクエストはありません。同じプライバシーモデルが他のツール、すなわち compare-text、compare-json、compare-yaml でも維持されています。コードレビューはレビュー対象が信頼できるときに最も機能します。