Line diff is not enough: word and character diffs for prose, config and JSON

Git diffs lines because source code is written in lines. Everything else you compare — a rewritten paragraph, a minified bundle, a
reformatted JSON blob, a translated string — is badly served by that assumption.

Three granularities, three jobs

• Line diff is right for code, configuration and anything where the line is the meaningful unit.
• Word diff is right for prose, documentation and commit messages, where one edited word should not paint the whole paragraph red.
• Character diff is right for near-identical strings: a changed API key, a hidden non-breaking space, a swapped digit in a version number.

Side-by-side versus unified

Side-by-side is better for reviewing: your eyes track two columns and you see structure. Unified is better for sharing: it is the
format every code host, mail client and terminal already understands. Being able to flip between them without re-running the
comparison means you can review one way and send the other.

Exporting a patch

A unified patch is a plain text file with a header, a hunk marker and prefixed lines. It applies with git apply or patch -p1,
which makes it the most portable way to hand someone a change when you cannot open a pull request.

Whitespace is usually the culprit

Before concluding two files differ meaningfully, check trailing whitespace, tabs against spaces, and line endings. A file edited on
Windows and committed from macOS often differs on every single line while being byte-identical in content.

Comparing files in a browser tab keeps unreleased text, customer data and private keys off someone else's server — the comparison
itself is pure string work, so there is no reason for it to leave your machine.