Diff Side by Side: From diff -y to Modern Workflows (2026)

Most diff tutorials stop at diff -u and call it a day. But the format developers actually reach for when reviewing a config change, comparing contract revisions, or eyeballing a data migration is diff side by side — two columns, aligned line by line, changes highlighted right next to each other. This guide covers every way to do a diff side comparison in 2026: the Unix CLI foundations (diff -y, sdiff), browser extensions and online tools, IDE integrations, and GUI apps — plus where each one fits into a real-world workflow.

The story of side-by-side diffing is really the story of developer tooling over five decades. The Unix diff command arrived in 1974 with a purely textual output format — useful for machines, readable for humans with practice. Side-by-side mode was added later as an acknowledgment that two columns are simply easier for humans to parse than a stream of + and - markers. Today, the same mental model lives in GitHub pull request views, VS Code's diff editor, and browser extensions that compare web pages or uploaded documents — all variations on the same two-column idea. For a deeper look at the foundational diff command in Linux/Unix — including all output formats and flags — see the companion guide.

What "Diff Side by Side" Actually Means

A diff side by side view places the original file in the left column and the modified file in the right column, with both synchronized so corresponding lines appear on the same row. Changed lines are highlighted inline; insertions show text in the right column with the left column blank (or vice versa for deletions). Side-by-side is one of the standard output modes of the diff utility, alongside the more compact unified format. The separator column between the two sides uses a symbol to indicate the relationship:

Contrast this with unified diff format, which interleaves the two files into a single stream using - for removed lines and + for added lines. Unified format is compact and excellent for patch files and machine parsing — it is exactly what git diff produces by default. Side-by-side format trades compactness for spatial clarity: you never have to mentally reconstruct where you are in the file because both versions are visible simultaneously.

The tradeoff is terminal width. Unified diff fits any terminal; side-by-side diff needs roughly twice the width to show both columns legibly. At 80-column terminals this becomes painful — each column gets 35–38 characters with the separator taking the middle. At 200 columns in a modern widescreen terminal or a browser, side-by-side is objectively more readable for anything beyond trivial changes.

diff -y and sdiff: The CLI Foundation

The canonical reference for side-by-side mode is the GNU diffutils manual on Side-by-Side format. Two commands produce it: diff -y and sdiff. They cover the same ground with slightly different defaults and a key interactive feature in sdiff.

Basic diff -y Usage

The simplest form:

diff -y file1.txt file2.txt

By default, this outputs both files aligned in two columns with a total width of 130 characters. A minimal example:

# file1.txt          file2.txt
apple               apple
banana            | blueberry
cherry              cherry
date              <
                  > elderberry

The | on the banana/blueberry row means the line exists in both files but the content differs. The < on the date row means that line was deleted (only in the left file). The > on the elderberry row means that line was inserted (only in the right file).

Essential diff -y Flags

--suppress-common-lines — Show only the differing lines. This is the most useful companion flag for large files where unchanged sections would bury the actual changes:

diff -y --suppress-common-lines file1.txt file2.txt

--width=N — Set the total output width. The default 130 is often too narrow for code. Bump it to match your terminal:

diff -y --width=200 file1.txt file2.txt

Ignore whitespace — Combine with -w or -b to suppress whitespace-only differences, useful after code formatting runs:

diff -y -w --suppress-common-lines original.js formatted.js

Color output — On GNU/Linux systems, add --color=always for highlighted output in color-capable terminals:

diff -y --color=always file1.txt file2.txt | less -R

sdiff: The Interactive Sibling

sdiff (side diff) was historically a separate program before being folded into GNU diffutils. Its output format is identical to diff -y, but it adds an interactive merge mode:

sdiff file1.txt file2.txt

The key differentiator is sdiff -o merged.txt file1.txt file2.txt: this launches an interactive session where you review each difference and choose which version to keep in the output file. For each change block, you type l (keep left), r (keep right), e (open editor), or s (silently keep left). It is a lightweight, terminal-only three-way merge workflow that predates every GUI merge tool.

diff -y vs sdiff: Which to Use

Both tools are part of GNU diffutils and available on any modern Linux or macOS system. For a comprehensive treatment of all eight Linux file comparison commands — cmp, comm, vimdiff, Meld, and more — see the guide to Linux compare files. On Windows, the equivalent side-by-side diff lives in PowerShell's Compare-Object or in GUI tools like WinMerge.

When Side-by-Side Beats Unified Diff

Neither format is universally superior — the right choice depends on the content and context. Here is a practical breakdown of when the diff side layout wins.

Code Review with Long Functions

When a function body is refactored, unified diff shows a long block of removed lines followed by a long block of added lines. Side-by-side keeps both versions of each line adjacent, so reviewers can see exactly what changed in place without mentally reconstructing the before and after. This is why GitHub's "split" view option is one of the most-used features in pull request reviews.

Multi-Paragraph Text and Documentation

Comparing two versions of a README, legal contract, or CMS article is significantly cleaner in side-by-side view. Unified format forces the reader to track whether they are reading the old or new version of a sentence; side-by-side makes it obvious at a glance. For comparing Word documents specifically, the guide to comparing Word documents covers Track Changes, redline views, and browser tools that all use side-by-side as the default format.

Schema and Configuration Comparisons

A database schema dump, Kubernetes manifest, or nginx.conf file changes infrequently but fatally when it does. Side-by-side makes the structural changes legible: you can see that a field was renamed (not deleted + added) by watching both columns move in sync. For database-level diffing, a dedicated DB comparison tool surfaces the same logic with schema-awareness.

HTML and Structured Markup

Attribute reordering and whitespace normalization produce extremely noisy unified diffs for HTML, XML, and similar formats. Side-by-side with -w (ignore whitespace) keeps the structural changes visible without the noise. The guide to comparing HTML online covers the additional semantic diff techniques that go beyond raw text comparison.

When Unified Diff Wins

For completeness: unified format is better for patch files (required by patch and git apply), email-based code review, and any context where terminal width is constrained or the output will be read in a narrow pane. The two formats are complementary, not competing.

Browser-Based Side-by-Side Diff Tools

Online diff tools exploded in the 2010s because most developers do not want to open a terminal just to compare two snippets pasted from Slack. The browser gives you a permanent URL, no installation, and often a better visual experience than a 130-column terminal window.

Online Diff Sites

Tools like Diffchecker.com, Mergely, and Text Compare load in any browser, accept pasted text, and show a side-by-side view by default. The core use case — paste left, paste right, click Compare — takes about 10 seconds. Most support switching to unified view, ignoring whitespace, and downloading the diff as a text file.

The main limitations of web-based diff sites: no local file processing (files are uploaded to servers), limited support for large files, no syntax highlighting for code in most free tiers, and session state that disappears when you close the tab. For sensitive code or regulated data, uploading to a third-party server is not an option.

Browser Extension: Diff Checker

The Diff Checker Chrome extension (version 1.1.11, Manifest v3) solves the privacy concern by running entirely in-browser — no content is ever sent to a server. It opens as a browser action (popup or new tab) and defaults to a side-by-side split view, switchable to inline/unified at any time. The setting persists across sessions via chrome.storage.local.

Key capabilities relevant to side-by-side work:

• Monaco Editor rendering — the same editor powering VS Code, with full syntax highlighting for 20+ languages: JavaScript, TypeScript, JSX/TSX, JSON, CSS, HTML, XML, Markdown, Python, Java, C, C++, C#, Bash, SQL, YAML, and more. Code looks like code, not plain text.
• File upload — text files (.txt, .js, .ts, .json, .html, .css, .md, .py, .java, .c, .cpp, .go, .rb, .php, .sql, .yaml) and Office documents (.docx, .xlsx, .pptx, .doc, .xls, .ppt, .odt, .ods, .odp, .pdf) up to 50 MB. No upload to a remote server — everything processes locally via Mammoth and XLSX libraries.
• Compare browser tabs — right-click any two open tabs to compare their page source. Useful for checking what changed between a cached and live version of a page or comparing two environments.
• Normalization options — whitespace normalization (CRLF→LF, trim, collapse blanks), JSON key sorting, CSS property sorting. Auto-detects format so you do not have to manually pick the mode.
• Compare methods — Smart Diff, Ignore Whitespace, and Classic LCS. The Ignore Whitespace mode is equivalent to diff -w on the CLI.
• Collapse unchanged sections — configurable context line count, analogous to --suppress-common-lines on the terminal.
• History with auto-save — sessions are persisted locally (debounced 500 ms), resumable without re-pasting.
• Format via Prettier — normalize JS, JSON, HTML, CSS, and YAML before diffing to eliminate formatting noise from the comparison.
• AI Summary (optional) — generates a structured summary of key changes using your own OpenAI API key. Disabled by default; uses GPT-4.1 Mini (or GPT-4o) when enabled. The diff content never leaves your browser for the AI feature either — it goes directly from your browser to OpenAI using your key.

The browser extension approach is particularly powerful for teams where not everyone is comfortable with the CLI. A product manager comparing two versions of a landing page, a technical writer diffing API documentation, or a DBA reviewing a schema change can all use the same tool without installing anything beyond the extension.

IDE & Editor Side-by-Side: VS Code, JetBrains, Vim

VS Code

VS Code's built-in diff editor is one of the most capable side-by-side experiences available without installing anything extra. You get it through several entry points:

• Command Palette — open two files, then run File: Compare Active File With... to pick the second file. VS Code opens a split editor with both files aligned side by side.
• Source Control view — clicking any changed file in the Source Control sidebar opens the diff editor automatically, comparing the working-tree version against the last commit.
• Timeline view — right-click a file in the Explorer, select Open Timeline, then compare any two historical versions.
• CLI launch — code --diff file1.txt file2.txt opens VS Code directly in diff mode.

The VS Code diff editor supports word-level highlighting (not just line-level), inline diff toggle, ignore whitespace mode, and navigation shortcuts between changes (Alt+F5 / Alt+Shift+F5 on Windows/Linux, Option+F5 on Mac). The full treatment of every method — including extensions and merge editor — is in the guide to comparing two files in VS Code.

JetBrains IDEs (IntelliJ, WebStorm, PyCharm, etc.)

All JetBrains IDEs include a powerful diff viewer accessible via View > Compare With... or by selecting two files in the Project panel and pressing Ctrl+D (or Cmd+D on Mac). The JetBrains diff view defaults to side-by-side, supports three-way merges, and integrates with the IDE's VCS tooling. It also handles binary files by showing a hexadecimal diff for supported types.

A notable feature: JetBrains IDEs highlight changes at the character level within a changed line, not just at the line level. This makes spotting a single changed variable name in a dense expression significantly faster than most other tools.

Vim / Neovim: vimdiff

For terminal purists, vimdiff (or nvim -d in Neovim) opens two files in a vertical split with differences highlighted and synchronized scrolling:

vimdiff file1.txt file2.txt
# Or equivalently:
vim -d file1.txt file2.txt

Navigation shortcuts: ]c jumps to the next change, [c to the previous. To pull a change from the other window: :diffget (or do). To push a change to the other window: :diffput (or dp). Run :diffupdate to refresh highlighting after manual edits.

vimdiff also supports three-way merge: vimdiff base.txt left.txt right.txt. This is the merge tool Git invokes when you set merge.tool = vimdiff in your Git config.

Git as a Bridge to Your Editor

You can route git diff through any diff tool with git difftool:

# Open changes in VS Code
git difftool --tool=vscode HEAD~1

# Open changes in vimdiff
git difftool --tool=vimdiff HEAD~1

# Word-level diff in terminal (no external tool needed)
git diff --color-words HEAD~1

git diff --color-words is a hidden gem: it shows changes at the word level in a single-stream view, which often reads more naturally than line-level for prose changes. Set your default difftool in ~/.gitconfig: git config --global diff.tool vscode.

GUI Apps: Meld, WinMerge, Beyond Compare, KDiff3

Standalone GUI diff tools have been the workhorses of Windows and Linux desktops since the late 1990s. They offer richer merge workflows than CLI tools and more control than web apps. The beyond compare alternative roundup covers nine tools in detail; here is a quick orientation for side-by-side use specifically.

Meld (Free, Linux/Windows)

Meld is the closest thing to a universal free GUI diff tool. It handles two-way and three-way file diffs, directory comparison, and version control integration (Git, Mercurial, SVN). The interface is clean, the side-by-side alignment is accurate, and it supports inline change highlighting. Available in most Linux package managers (apt install meld) and Windows (MSI installer). macOS support is not yet official, though semi-official builds are available through Homebrew, MacPorts, and Fink.

Best for: Linux power users, three-way merge resolution, anyone who wants Beyond Compare functionality without the price tag.

WinMerge (Free, Windows only)

WinMerge is the go-to free diff tool on Windows. It supports files, folders, archives, and — in recent versions — image comparison. Side-by-side view is the default; the highlight colors are configurable. Integrates with the Windows shell (right-click > WinMerge). The guide to directory comparison on Mac covers the macOS equivalent options for those who need cross-platform coverage.

Best for: Windows teams who need a free, capable diff tool with shell integration.

Beyond Compare (Paid, cross-platform)

Beyond Compare (Standard Edition $35, Pro Edition $70, one-time purchase) is the commercial standard for serious diff work. It handles text files, binary files, folders, archives, FTP/SFTP comparisons, and database connections. Its "Text Compare" view uses side-by-side as the default and adds configurable highlighting, grammar rules, and importance filters that let you hide irrelevant differences. Available on Windows, macOS, and Linux.

Best for: developers or ops teams who do heavy file and folder comparison work and want the fastest, most configurable experience.

KDiff3 (Free, cross-platform)

KDiff3 is a Qt-based tool that excels at three-way diffs and merges. If you regularly resolve merge conflicts in complex files, KDiff3's three-panel layout (base, local, remote + output) is hard to beat for free software. Less polished than Meld or Beyond Compare on the UI side, but highly capable.

Best for: three-way merge resolution, KDE/Qt environments, anyone needing merge output saved to a file.

icdiff (Terminal, color-aware)

Worth a mention: icdiff is a Python-based command-line tool that produces colorized side-by-side output in the terminal without the width limitations of diff -y. It handles unicode cleanly and is installable via pip install icdiff. A good middle ground between raw diff -y and a full GUI.

Side-by-Side Diff in Real Workflows

The practical reality of 2026 is that most side-by-side diff work happens embedded inside larger workflows, not as standalone file operations. Here is where the diff side by side view shows up in everyday developer work.

GitHub and GitLab Pull Requests

Both GitHub and GitLab offer a "Split" view toggle on every pull request diff. Click "Split" at the top of any changed file view to switch from the default unified view to a two-column layout. This is, by volume, how most side-by-side diffing happens in the industry today — not in terminals or GUI apps, but inside code review platforms.

Both platforms also support collapsing unchanged sections and hiding whitespace changes in split view, which makes large refactor PRs far easier to review without losing the signal in formatting noise.

Slack and Email Code Snippets

When a colleague pastes a before/after code snippet in Slack or email, the fastest diff is a browser extension: copy both blocks, open the extension, paste, compare. The side-by-side view immediately highlights what changed in the snippet. No terminal, no temporary files, no losing context by switching applications.

CMS and Documentation Reviews

Content teams reviewing draft versus published versions of articles, landing pages, or knowledge base entries use side-by-side diff tools more than developers might expect. A product manager comparing two versions of pricing page copy is doing the same operation as a developer reviewing a config change — they just want a web-friendly interface.

The browser extension's file upload capability handles this directly: upload two .docx or .pdf versions and get an immediate side-by-side text comparison. For dedicated Word document comparison workflows, the guide to comparing Word documents covers Word's built-in Track Changes, redline tools, and browser-based methods.

Database Schema Migrations

Before applying a database migration, diffing the current schema dump against the target state is a sanity check that catches dropped columns, renamed constraints, and unintended index changes. Side-by-side view makes the structural changes legible at a glance. A MySQL database compare tool handles this at the database level; for schema files in version control, diff -y or the IDE diff editor works well.

Static Analysis Baselines

When running static code analysis in CI, comparing the current lint report against the baseline report tells you whether a PR introduced new violations or resolved existing ones. A side-by-side diff of the two reports surfaces that immediately. Teams that use diff as a feedback mechanism — not just as a review artifact — find side-by-side format significantly faster to parse than unified diff for this use case.

Side-by-Side Diff Tools Compared

Every tool covered in this guide occupies a different point in the tradeoff space. Here is a summary to help you pick the right one for a given situation.

A few selection heuristics:

• Terminal + scripting: diff -y with --suppress-common-lines. No dependencies, available everywhere, scriptable.
• Code review in PRs: GitHub/GitLab split view. Already where the review happens; no context switching.
• IDE-based review: VS Code diff editor (code --diff) or JetBrains built-in. Best syntax highlighting and navigation.
• Quick browser paste (sensitive code): Diff Checker extension. Private, no upload, Monaco syntax highlighting, history.
• Three-way merge resolution: Meld (free) or KDiff3. Dedicated panels for base/local/remote.
• Heavy folder/file ops: Beyond Compare (paid). Fastest, most configurable.
• macOS CLI without GUI: diff -y or FileMerge / opendiff (built-in on macOS with Xcode Command Line Tools).
• Binary files: cmp, xxd hex diff, or HxD — covered in detail in the binary compare guide. Most side-by-side text diff tools handle binary files poorly or not at all.

Common Pitfalls & How to Avoid Them

Terminal Width Truncation

The most common frustration with diff -y: lines get truncated at column 65 because the default total width is 130. At 80-column terminals, each column is barely 35 characters. Fix it with --width=$(tput cols) to match your current terminal width:

diff -y --width=$(tput cols) --suppress-common-lines file1.txt file2.txt

Or set a fixed wide value: --width=220. Long lines will still wrap inside each column, but at least you see the full content.

Word-Level vs Line-Level Differences

Standard diff — including diff -y — operates at the line level. If a single word changes in the middle of a long paragraph, the entire line is flagged as changed. For prose-heavy content, use git diff --color-words, the word-diff option in wdiff, or a browser extension that highlights changes at the word or character level.

The Diff Checker extension's Monaco-powered view highlights changes at the character level within changed lines, which is substantially more informative than whole-line highlighting for dense code.

Encoding and Line-Ending Mismatches

CRLF vs LF differences make every single line appear changed in a diff side by side view. On GNU/Linux, add --strip-trailing-cr to diff -y:

diff -y --strip-trailing-cr file_windows.txt file_unix.txt

Character encoding mismatches (UTF-8 vs Latin-1, BOM presence) produce similar noise. Normalize encoding first with iconv or your editor's encoding conversion. The binary comparison guide covers the edge case where files look identical as text but differ at the byte level due to encoding — see the binary compare guide for the cmp and xxd approach.

Large Files and Performance

The LCS (longest common subsequence) algorithm that diff uses is O(n×m) in the worst case. Files over ~10,000 lines can cause noticeably slow output. Mitigations:

• Use --speed-large-files — trades diff quality for speed by using a heuristic that avoids the worst-case O(n×m) paths.
• Use --suppress-common-lines to reduce the output volume if you only care about changed lines.
• For very large log files or data dumps, split into smaller segments and diff those.
• Browser-based tools (including the Diff Checker extension) warn at 25 MB and cap at 50 MB to prevent browser memory exhaustion.

Comparing Minified or Machine-Generated Files

Minified JavaScript, machine-generated JSON, or compiled CSS files produce a single-line diff that is effectively unreadable. Always format before comparing:

• In the Diff Checker extension, use the Format via Prettier button before comparing.
• On the CLI: cat file.json | python3 -m json.tool > file_pretty.json, then diff the pretty-printed versions.
• For JSON specifically, the extension also offers JSON key sorting normalization — useful when key order changes between API responses.

Assuming Side-by-Side Is Always More Readable

Side-by-side diff is harder to read when the two files have very different line counts — the alignment breaks down and the two columns stop representing "corresponding" content. In this case, unified format (or a structural diff tool) often gives a cleaner picture. Similarly, for binary files, side-by-side text mode is meaningless — use cmp or a hex viewer.

Frequently Asked Questions

How do I show diff side by side in the terminal?

Run diff -y file1 file2 to print both files in two aligned columns. Add --suppress-common-lines to hide identical rows and -W (or --width=N, e.g. -W 200) to widen the output beyond the default 130 columns, which is usually too narrow for code.

What is the difference between diff -y and sdiff?

Both produce the same side-by-side layout. diff -y is read-only — it just prints two columns to stdout. sdiff adds an interactive merge mode (sdiff -o merged.txt file1 file2) that prompts you to pick the left or right version of each conflicting hunk and writes the result to a new file.

How do I view Git diffs side by side?

git diff outputs unified format by default. For a side-by-side view, run git difftool against an external tool (Meld, Beyond Compare, VS Code, Kaleidoscope). For lighter inline emphasis, git diff --color-words highlights changed words within a single column. VS Code's Source Control panel and its 3-way merge editor also render side-by-side diffs natively.

What is the best side-by-side diff tool for Mac?

On macOS the strongest picks are Kaleidoscope (paid, Mac-native), Beyond Compare (paid, cross-platform with deep folder diff), and VS Code (free, built-in diff editor). For quick terminal work diff -y and sdiff ship with macOS. For zero-install browser-based side-by-side diff, Diff Checker's Chrome extension uses Monaco with in-browser processing.

Can I diff side by side without installing anything?

Yes — a browser extension or web app handles it with no install footprint. The Diff Checker Chrome extension renders side-by-side diff using the same Monaco editor that powers VS Code, with all processing kept local so your text never leaves the machine. Most online diff sites work without an account but upload your pasted text to their server, so pick a local or in-browser tool for anything sensitive.