Text Diff Viewer - Compare Two Texts Side by Side

How to use this tool

1. Paste your original text. Click into the "Original" textarea on the left and paste the text you want to use as the baseline - for example, the contents of a file before editing.
2. Paste your modified text. Click into the "Modified" textarea on the right and paste the updated version of the text.
3. Read the diff. The diff view appears immediately. Red lines were removed, green lines were added, and partially-changed lines appear with inline highlighting showing exactly which words or characters changed.
4. Switch view modes. Use the "Side by side" and "Unified" buttons in the toolbar to switch between a two-panel view and the traditional unified diff format.
5. Adjust ignore options. Check "Whitespace", "Case", "Empty lines", or "Trailing spaces" to filter out noise that you do not care about - useful when comparing configs or code with minor formatting differences.
6. Export the patch. Click "Copy patch" to copy the diff in standard unified patch format, ready to share or apply with `git apply`.

What is a text diff?

A diff (short for difference) is a comparison between two versions of a text that shows exactly what changed: which lines were added, removed, or modified. Diffs are fundamental to software development: every time you run git diff or review a pull request, you are reading a diff.

This tool performs the comparison entirely in your browser. Nothing is sent to a server. You can paste confidential configuration files, private source code, or sensitive documents without worry.

How to read a diff

There are two common display formats:

• Side-by-side: the original text appears on the left, the modified text on the right. Removed lines are highlighted red on the left; added lines are highlighted green on the right. Lines that exist on both sides but changed are shown in both panels with word- or character-level inline highlighting to pinpoint the exact change.
• Unified: both texts are merged into a single column. Lines prefixed with - were removed; lines prefixed with + were added; unprefixed lines are context (unchanged). Unified diffs are the standard format used by Git, email patches, and code review tools.

Line vs word vs character diff

This tool always performs a line-level diff first: it identifies which lines changed. For lines that were partially changed (not entirely replaced), it then performs a secondary inline diff to highlight the specific words or characters that changed within that line:

• Word diff: splits each line on whitespace and highlights changed words. Best for prose, configuration values, and most code.
• Char diff: highlights individual changed characters. Best for spotting single-character typos or small symbol changes.

Ignore options explained

• Ignore whitespace: normalises all runs of whitespace (spaces and tabs) to a single space before comparing. Lines that differ only in indentation or spacing are treated as equal. Useful for comparing reformatted code.
• Ignore case: converts both sides to lowercase before comparing. Lines that are identical except for capitalisation are treated as equal.
• Ignore empty lines: strips blank lines from both sides before diffing. Handy when one version has extra blank lines inserted by an editor.
• Ignore trailing spaces: trims whitespace from the end of each line before comparing. Prevents spurious differences caused by editors that add or remove trailing spaces.

Exporting as a patch file

Click Copy patch to copy the diff in standard unified patch format. You can paste this into a .patch file and apply it to the original file:

patch -p1 < changes.patch

Or apply it with Git:

git apply changes.patch

The patch format is compatible with GNU patch, Git, and most other diff/patch tools.

Understanding Git merge conflict format

When Git cannot automatically merge two branches, it inserts conflict markers directly into the file. Understanding this format helps you resolve conflicts manually:

<<<<<<< HEAD
content from the current branch (your changes)
=======
content from the incoming branch (their changes)
>>>>>>> feature-branch

The section between <<<<<<< HEAD and ======= is what your branch currently has. The section between ======= and >>>>>>> is what the branch being merged in has. Resolving the conflict means choosing one version, combining them, or writing a third option - then deleting all the conflict markers.

Common use cases beyond code

• Contract revisions: compare two versions of a legal document to verify only the intended changes were made.
• Configuration files: check whether two environment configs are identical or spot unexpected differences.
• Translated text: compare source and target language texts side by side to verify completeness.
• Policy documents: track changes between published versions of privacy policies, terms of service, or regulatory filings.