How to export text differences as a unified diff
Compare two versions of text, export their changes as a unified diff, and check the result before sharing or applying it.
You have two versions of a text file and need to show exactly what changed. A unified diff puts additions and removals in a compact, line-based format that is easy to review and can be used by many developer tools.
Use Text Compare to compare the original with the revised text, then export the result in unified diff format. Check the headers and changed lines before you send it or try to apply it.
Export the differences
- Open Text Compare. Put the earlier version in the original text area and the newer version in the other area. Keep the order consistent so additions and removals are easy to read.
- Compare the two versions. If the output includes many unexpected changes, check that each text area contains the complete version you intended to compare.
- Choose unified diff as the output format. If the tool offers options for context lines, keep some surrounding unchanged lines so a reader can understand where each edit belongs.
- Use the tool's export or copy option to save or copy the unified diff. If you download it, use a clear name such as
update.difforchanges.patch. - Open the exported text and review the file headers, changed lines, and final line endings. Make sure the diff shows the changes you expect before sharing or applying it.
Choose the right diff output
A unified diff is a plain-text record of changes. It does not include the full contents of both versions. Instead, it shows file labels, small sections of nearby unchanged lines, and lines that were removed or added.
Keep context lines for review
Context lines are unchanged lines shown around an edit. They usually begin with a space in the diff. A few lines of context make it easier to identify the location and meaning of a change, especially when the diff is reviewed separately from the original files.
If the tool lets you choose how much context to include, a small number of lines is usually enough for review. More context makes the diff longer. Less context makes it harder to see where an edit belongs, and may make a patch harder to apply if the surrounding text has changed.
Use minimal output for a short change
A diff with little or no context can be useful when you only need a compact record of what changed. It may be less useful for another person who needs to locate the change in a larger file. Keep the original and revised files available if you share a minimal diff.
Remember that line changes can look larger than they are
Unified diffs compare lines, not individual words. If you edit one word in a long paragraph, the output may show the old paragraph as removed and the revised paragraph as added. That is normal. Check the text itself rather than assuming that every marked line is a completely new idea.
How to fix a diff that looks wrong
- Check which version is in each side. Put the earlier text first and the revised text second. Reversing them reverses the direction of additions and removals.
- Remove accidental blank lines. Extra spaces or blank lines at the beginning or end of pasted text can appear as changes. Compare the ends of both inputs and remove anything that was added by mistake.
- Check line endings and whitespace. Some files use different line endings or trailing spaces. A whole file may appear changed even when the visible words look the same. If possible, compare files saved with the same line-ending convention and avoid editing whitespace during the comparison.
- Confirm the text is complete. A missing final section or an incomplete paste creates a real difference. Compare the beginning and end of each input with the source files before exporting again.
- Choose more context if the diff is hard to place. If the output will be used to review or apply a change, include enough nearby unchanged lines to identify the edit's location.
- Check the output format again. Make sure the exported content is unified diff text, not a side-by-side comparison or a full copy of one input. If another program will consume it, confirm that program accepts unified diffs.
Read the main parts of a unified diff
A typical unified diff uses lines like --- old-file.txt and +++ new-file.txt to label the compared versions. The names can be descriptive labels or file paths. They identify the sides of the comparison, but do not guarantee that the files are stored at those locations on your computer.
A section marker such as @@ -10,4 +10,5 @@ describes a changed area. The numbers refer to line positions and counts in the old and new versions. Within that section, a line beginning with - was removed, a line beginning with + was added, and a line beginning with a space is unchanged context.
For example, a removed sentence followed by an added sentence usually means the original line was replaced. A plus sign or minus sign at the start of a diff line is a marker, not necessarily part of the text itself. Read the full line after the marker to see the actual content.
Know what the export can and cannot do
A text diff is not a comparison for photos, PDFs, or other binary files. It also does not prove that the revised file is correct. It records differences between the text you supplied, so review important edits and keep a separate copy of the originals.
A unified diff may be accepted by patching tools, but applying it can fail if the target file has changed since the comparison or if its path and line context do not match. Review the target files and keep a backup before applying changes.
