A line-level diff between two files in Linux shows exactly which lines were added, removed, or left untouched, and you can produce that comparison entirely in your browser with the Diff Checker — no terminal, no upload, no server. The tool reads the original text on the left, the changed text on the right, and runs a classic dynamic-programming algorithm called the Longest Common Subsequence (LCS) over both inputs in JavaScript. That is the same approach behind the Unix diff utility, Git's commit view, and the side-by-side change displays in GitHub and GitLab, so the output you see lines up with the kind of report a terminal command would print. Lines marked with a leading + were added in the new version, lines marked with - were removed from the original, and a small summary at the bottom keeps a running count of each. Because everything runs client-side, two pasted file dumps never leave your machine, which makes the tool appropriate for source code, server configuration snippets, and any other text that should not be uploaded to a third-party backend.
Where Linux file comparison shows up
Comparing two versions of a text file is a routine task on a Linux box, and the situations that call for it follow the same pattern again and again. A few common cases:
- Configuration drift. Two servers should share the same nginx.conf or sshd_config, but a manual edit on one of them has crept in. A diff highlights the exact line that drifted.
- Code review before a commit. You have rewritten a function locally and want to confirm the change is small and intentional before you stage it.
- Log analysis. Two captures of the same service from before and after a deploy can be diffed to spot the lines that newly appeared.
- Script updates. A teammate sent you a revised version of a Bash or Python script and you want to verify only the lines they mentioned changed.
- Template versus filled-in form. A blank YAML or INI template next to a populated version shows which fields were filled and which were left at defaults.
- File identity check. Two exports of the same dataset should be byte-identical, and a zero-line diff proves that quickly.
Each of these cases has the same shape: two text files, a question about which lines changed, and no need to merge or rewrite the documents.
Comparing two files on Linux: terminal commands and a browser alternative
On a Linux system the native way to compare two files is the diff command, which has been part of GNU coreutils for decades. The simplest invocation lists the lines that differ:
diff original.txt changed.txt
Add -u to get a unified format with a few lines of context around each change, which is also the format that git diff and most code-review tools render. Other options that ship on most distributions include colordiff (the same output, colorized for the terminal), vimdiff (a side-by-side view inside Vim), and meld or diffuse for a graphical three-way merge. All of these run locally, need no network, and are reliable choices when you have shell access to the box that holds the files.
The trade-off is friction. You need the package installed, you need a terminal session, and you need to read the result in the same place you ran the command. If the files live on a workstation you do not administer, or if you are working from a Chromebook, a managed laptop, or a sandbox where installing packages is restricted, those options are not always available. A browser-based diff is a practical alternative in those cases: open the Diff Checker, paste the two file dumps into the two boxes, and read the same kind of line-by-line report you would get from diff -u, without the install step.
Run a diff check in your browser
The browser flow is the same regardless of where the two files live on disk. You copy their contents into the two text boxes and read the report underneath.
- Open the Diff Checker in any modern browser. No login, no extension, no install step.
- Paste the contents of the original file into the left box labelled "Original". A plain cat file.txt or a copy from your editor is enough.
- Paste the contents of the new version into the right box labelled "Changed".
- Read the line-by-line result below the two boxes. Lines that begin with + were added in the new version; lines that begin with - were removed from the original; lines without a marker stayed the same.
- Glance at the summary under the result to confirm the count of added, removed, and unchanged lines. The comparison updates as you type, so you can keep editing either side and watch the diff recompute in real time.
For everyday scripts, config files, and document drafts the comparison is effectively immediate.
Reading the output: what +, -, and the counts mean
The visual convention of + for additions and - for deletions is the same one diff -u uses, so anyone who has read a patch before will recognize it at a glance. The interesting part is what stays aligned when you change one line in the middle of a long file. The tool does not just compare line 1 to line 1, line 2 to line 2, and so on; it first finds the longest run of lines that appears in both files in the same order and treats that run as a shared backbone. Everything outside the backbone is then reported as an addition or a deletion. The net effect is that an edit to line 47 of a 200-line file shows up as one removed line and one added line at position 47, while lines 48 through 200 stay aligned and unflagged.
This approach, called the Longest Common Subsequence algorithm, is the same dynamic-programming technique that powers the Unix diff utility, the comparison view in Git, and the side-by-side change view in hosted Git platforms. Two practical consequences for reading the output:
- The markers use both a leading + or - and a background color. If your viewer strips color (a terminal without color support, a printed page, a paste into plain-text notes), the markers still convey the change.
- Lines that differ by even a single character are reported as one removal plus one addition, not as a partial in-place edit. That is the right granularity for source code, configuration, and prose, where the meaningful unit of change is the whole line.
The summary at the bottom of the result adds three totals: the number of lines added, the number removed, and the number of lines that appear unchanged in both files. A clean audit, where the two files are identical, produces a zero in the added and removed columns and every line counted as unchanged.
What line-level diff handles well
Line-level comparison is the right tool for the kinds of text files Linux users deal with every day, and the wrong tool for a few edge cases. The table below summarizes the fit.
| File or content type | Line-level diff suitable? | What to expect |
|---|---|---|
| Source code (any language) | Yes | Each line is a natural unit; whole-line changes are the usual commit shape. |
| Configuration files (nginx, sshd, systemd units) | Yes | A single-line change such as a new listen directive shows as one addition or removal. |
| Log files (syslog, journald exports) | Yes | New or removed log lines are visible immediately. |
| JSON, YAML, TOML | Yes (after formatting) | Pretty-print first so the meaningful lines align; compact JSON produces noisy diffs. |
| CSV | Yes | Each row is one line, so added or removed rows stand out. |
| Prose and Markdown | Yes | Paragraphs map cleanly to lines; a one-character typo still shows as a removed and added line. |
| Compiled binaries, images, archives | No | Use cmp or a hex tool such as xxd instead; line-based text diff has no meaning here. |
If a one-character edit inside a long line matters to you, a line-level diff will show the entire old line and the entire new line side by side, and you can read the difference with your eyes. For character-level precision in structured formats such as JSON, a structural diff over a parsed tree is a better fit, but for the everyday what-changed-in-this-file question, line-level is the standard answer on Linux and elsewhere.
Keeping sensitive Linux files off the network
Linux servers hold a lot of text that is worth comparing and that you do not want to leave the machine: private SSH keys in ~/.ssh/config, internal API tokens in .env files, unpublished documentation, customer data exports, signed contracts, and proprietary source code. Most online diff tools accept your text by POSTing it to a backend, which means the contents of your file pass through a third-party server on the way to a result.
The Diff Checker takes a different path. The two texts you paste are compared entirely in your browser with JavaScript, so no network request carries the file contents away. Closing the tab drops the in-memory data, and a page refresh starts a clean slate. The trade-off is that very large inputs (many thousands of lines) need proportionally more memory but for the everyday scripts, configs, and document drafts that fit on a single screen, the comparison is fast and stays local. If you routinely work with material that should not leave the box, that privacy posture is usually the deciding factor over the choice between a terminal diff and a browser-based one.
Related reading: How to Generate a Linux Directory Tree From Path Lists.