Side-by-Side vs Unified Diff: How to Compare Text

You pasted two versions of a file into a diff tool and got a wall of plus and minus signs — or two columns with cryptic bars between them — and you are not sure which view is telling you the truth. They both are. Unified and side-by-side are two layouts for the same set of changes. Knowing how each one reads, and when to reach for it, turns a confusing diff into a thirty-second review.

#TL;DR

• Unified diff stacks old and new in one column with -, +, and context lines.
• Side-by-side splits old (left) and new (right) into parallel columns with a gutter marker.
• The @@ -a,b +c,d @@ hunk header points a patch tool at the exact lines.
• Use unified for patches and code review; side-by-side for prose and wide rewrites.
• A browser-based Diff Checker shows both views with no upload.

#What a diff actually computes (the difference explained)

Before the layout matters, it helps to know what a diff is. A diff is not a character-by-character comparison. It is the shortest set of insertions and deletions that turns the first text into the second — and the layout you see is just a rendering of that edit script.

#How diff finds changes: the Myers algorithm

Most diff tools, including Git, default to the greedy algorithm from Eugene W. Myers's 1986 paper An O(ND) Difference Algorithm and Its Variations. Per the Git diff-options documentation, myers is the default, with minimal, patience, and histogram available through --diff-algorithm. Myers walks an edit graph and finds a path with the fewest deletions and insertions, which is why a one-word change usually shows as one line out, one line in — not the whole paragraph.

#LCS: the longest common subsequence

Underneath, the problem is the longest common subsequence (LCS): the largest set of lines that appear, in order, in both texts. Everything not in the LCS is a change. This is why diffs are line-oriented by default — they treat each line as an atom and ask whether it survived from old to new. It is also why reformatting a file can produce a noisy diff: you changed every line's whitespace, so almost nothing matches.

#Why two tools can show the same change differently

Two diff tools can render the identical edit and still look different because they made different alignment choices. When several lines could plausibly pair up, the algorithm picks one mapping. The histogram algorithm, for example, prefers to anchor on rare lines first, which often produces a more intuitive grouping than greedy Myers. The change is the same; the story the diff tells about it shifts.

#How to read a unified diff

Unified format is what you get from git diff, diff -u, and nearly every code-review tool. It is compact and machine-readable, which is why it doubles as a patch you can apply.

#What the @@ hunk header means

A unified diff is a series of hunks — each a region where the files differ, padded with a few shared lines. Per the GNU diffutils manual, each hunk opens with a header wrapped in @@:

@@ -12,7 +12,8 @@ def render(self):
 context line stays
-old line removed
+new line added
+another new line
 trailing context

Read @@ -12,7 +12,8 @@ as: the old file's region starts at line 12 and spans 7 lines; the new file's region starts at line 12 and spans 8 lines. The text after the closing @@ is the function or section the hunk sits in — useful orientation, not part of the math.

#The +, -, and space line prefixes

Inside a hunk, the first character of every line is a marker:

• A leading space means the line is unchanged context, present in both files.
• A leading - means the line was removed from the old version.
• A leading + means the line was added in the new version.

A modified line therefore appears twice — once as - and once as +. That is the single most common point of confusion: a unified diff does not have an "edited" marker. Every change is a delete plus an insert.

#How to widen context with -U

By default diff includes three context lines around each change. You can widen that with -U5 (or any number) on the diff command, or git diff -U10. Wider context makes a patch more resilient: if the surrounding file has drifted since the patch was made, more anchor lines help the patch tool find the right spot. Narrower context produces a smaller diff but a more fragile patch.

#How to read a side-by-side diff

Side-by-side format places the two files in parallel columns so your eye can compare them directly, the way the diff -y command or GUI tools like Meld and KDiff3 present changes.

#The gutter markers: |, <, and > explained

The columns are separated by a small gutter, and the character in that gutter classifies each row. In GNU diff -y output, a blank gutter means the two lines are identical, a | means the line changed, a < means a line exists only on the left (removed), and a > means a line exists only on the right (added). One glance down the gutter column tells you the shape of the change without reading either side in full.

the quick brown fox        the quick brown fox
jumps over the dog       | leaps over the dog
                         > a brand new line
shared closing line        shared closing line

#When side-by-side beats unified

Side-by-side shines when changes are within lines rather than whole-line swaps. Reword a sentence and a unified diff drops the entire old line and adds the entire new one, leaving you to spot the four changed words yourself. Side-by-side parks the two versions next to each other so the difference is spatial. It is also kinder for wide rewrites where many lines changed at once and a unified diff becomes a solid block of red and green.

#Width and truncation gotchas

The trade-off is width. The GNU manual notes that side-by-side output is normally 130 columns wide because each row carries two input lines, and lines too long for half the width are truncated. On a narrow terminal or a phone, long lines get cut off, and you can miss a change that happened past the truncation point. For long lines, unified — which uses the full width per line — is safer.

#Side-by-side vs unified diff: which should you use?

There is no universally correct format; there is a correct format for the task in front of you. Here is the quick mapping.

#For code review and pull requests

Pull-request tooling leans unified because the diff is the patch — it can be applied, reverted, and commented line by line. For typical code changes (a few lines per hunk, generous context), unified is compact and unambiguous. Most reviewers never switch away from it, and that is fine.

#For prose, contracts, and translations

For natural language, side-by-side usually wins. When you tighten a paragraph or a lawyer redlines a clause, the edits are sub-line and the surrounding text barely moves. Reading the old and new sentence side by side beats mentally stitching a - line to a + line. The same goes for comparing a source string to its translation, where you want both languages visible at once.

#For patches and machine-readable output

If the output needs to be consumed — applied with patch, fed to a script, attached to an email — unified is the only sensible choice. Side-by-side is a human-reading layout with gutter glyphs and alignment padding that no patch tool understands. When in doubt about whether a machine will read it, use unified.

#How to diff two texts in your browser (no upload)

You do not need Git installed, a terminal, or an account to compare two blocks of text. A client-side tool does it in the page.

#Paste, compare, switch views

Open iKit's Diff Checker, drop the old text on the left and the new text on the right, and the comparison renders instantly. You can read it as parallel columns or flip to a unified view — same underlying edit script, your choice of layout — and toggle word-level highlighting to pinpoint exactly which characters changed inside a modified line.

#Diffing JSON and Markdown without noise

Structured text is where diffs get loud. Two JSON objects that are semantically identical but formatted differently produce a diff full of cosmetic churn. Run both through the JSON Decoder to normalize formatting first, then diff — the result shows only the values that actually changed. The same trick works for prose written in the Markdown Editor: compare two drafts without Word's track-changes baggage.

#Why client-side diffing matters for secrets

Comparing two .env files, an API response, a contract, or a production log means handling text you should not paste into a random server. A browser-based diff never transmits your input — the JavaScript runs in your tab and the bytes stay on your machine. That is the same no-upload principle behind every iKit tool, and it is the difference between a private comparison and an accidental data leak.

#References

• Detailed Description of Unified Format — GNU diffutils manual — primary source for the @@ hunk header, the +/-/space prefixes, and the two-line file header.
• Controlling Side by Side Format — GNU diffutils manual — the 130-column default width, gutter separator, and long-line truncation behavior of diff -y.
• Git diff-options Documentation — confirms myers is the default diff algorithm and documents minimal, patience, and histogram via --diff-algorithm.
• git-diff Documentation — unified output as Git's default and git difftool for external side-by-side viewers.

#Related on iKit

• Compare any two texts in seconds with a browser diff checker — the companion walkthrough of the same tool, focused on the paste-and-compare workflow rather than the format internals.
• Format both JSON blobs before you diff them — normalizing two JSON files to a consistent shape first is what stops a diff from drowning in cosmetic whitespace noise.
• When you need to find a pattern, not compare two texts — a sibling browser text tool for the cases where a search expression beats a line-by-line diff.
• Why iKit runs entirely in your browser — the no-upload architecture that lets you diff secrets, contracts, and logs without sending them anywhere.