Skip to content

Text Diff Compare

Pure frontend: paste two texts, compare line by line, color-mark added / removed / unchanged. Nothing leaves your browser — no network call, nothing recorded.

How to use

Paste the "old text" on the left, the "new text" on the right, click Compare, and the result lists lines below: red is unique to the old text (removed), green is unique to the new (added), grey is identical on both sides. A difference count sits at the top.






What diff actually compares


This tool aligns the two texts line by line with LCS (longest common subsequence): first it finds the lines both sides share in the same order as "same", then the rest are each side's unique lines, marked removed or added. This alignment makes a change read as "old line replaced by new line" instead of a scrambled mess.


Why by line and not by character? Because what ops compares most is config, logs, scripts — their structure is one line per entry. Changing one parameter in a line is clearer as "delete + add the line" than char-by-char red.


Best-fit scenarios


    

  • Config drift check: two nginx.conf or two k8s manifests — exactly which parameter lines changed, at a glance.
    • 

  • Log snippet compare: an access log when healthy vs when erroring, line by line you spot the extra or missing request.
    • 

  • Two script versions: paste your before and after, confirm the change scope and that nothing was accidentally deleted.
    • 

  • Pre-deploy sanity check: diff the staging config against production to avoid shipping a diff to live.
    • 



Three traps people hit first


Invisible newline difference: Linux uses LF (\n), Windows uses CRLF (\r\n). Same content, one \r at the end, and diff calls it different. Common when pasting across platforms. Normalize newlines first (editor "convert to LF"), or pre-process with "trim + unify newlines".


Trailing space and full/half width: an extra space at line end, a Chinese comma ， vs English ,, full-width vs half-width brackets — the eye barely tells, but diff flags it red. In configs such differences are sometimes real problems (YAML indent, parameter value) and sometimes pure typo; judge by context.


Encoding difference: under UTF-8 vs GBK the same Chinese character has different bytes, so the whole line is judged different. Make sure both sides are UTF-8 before comparing.


Line-level vs character-level


The limit of line-level diff: change one character in a line and the whole line becomes "delete + add", and you still have to eyeball that line for the exact change. If the task is "which few characters in this line changed", you need a char-level (word/char) tool — an editor's inline diff or git diff --word-diff. This tool's job is quickly seeing the change scope; leave character precision to specialist tools.


Relation to git diff


git diff is version-control based on two commits; beyond line diffs it does char-level, detects renames, and marks merge conflicts. This tool does not depend on git and keeps no history — a lightweight stand-in for "compare two texts on the spot". They complement: use git for daily version history, use this tool for an ad-hoc two-text check.


A config-drift example


Suppose the old config B and new config A are two Nginx upstream blocks:


# A (old)
upstream api { server 10.0.0.1:8080; server 10.0.0.2:8080; }
# B (new)
upstream api { server 10.0.0.1:8080; server 10.0.0.3:8080; }



After comparing you see: the first line is the same, and in the second line 10.0.0.2 is flagged red (removed) while 10.0.0.3 is flagged green (added) — instantly locating "the backend node changed from .2 to .3". Such a change is easy to miss flipping through two long configs by eye; one diff exposes it.


How LCS aligns, in plain words


Forget the math; remember one sentence: it first finds the longest same-ordered lines on both sides as anchors, and whatever remains is the difference. For example, if lines 1, 3, 5 are shared, they align first, and the differences in lines 2 and 4 get isolated and marked. So it is not "compare line by line with ==", but allows insertions/deletions in the middle and still aligns — exactly what makes it smarter than a naive per-line equality. The cost is compute growing with the square of line count, so beware huge files.


What else you can compare


Beyond configs, these come up often:


    

  • DNS zone files: which record was added/removed, whether TTL changed — line-by-line is clearest.
    • 

  • Firewall / security-group rules: rules match in order, and adding or removing one can change the whole chain's behavior; a diff confirms "exactly which rule moved".
    • 

  • Cron expression lists: which task's schedule changed, one task per line, one diff shows it.
    • 

  • Environment variable files (.env): which keys were added, which values changed — but note .env holds secrets; after comparing, do not leave the content in the browser or screenshot it outward.
    • 



Pre-processing tips before comparing


To see fewer "fake differences", two things help before you compare:


    

  1. Unify newlines and trim whitespace: in the editor, convert both sides to LF and strip trailing spaces; that kills most "looks same but differs".
    2. 

  2. Sort then compare: if the two sides are set-like (an IP list, a domain list), sort each by line first; the diff then focuses on "what was truly added/removed" instead of huge fake churn from reordered lines.
    3. 



Do both outside this tool with an editor or the sort command, then paste in — the result is far cleaner.


Get the compare direction right


Put A on the left and B on the right: red means "in A but not B" (a removal from A's view), green means "in B but not A" (an addition). Swap the sides and the red/green meaning swaps too. When reporting a diff, state the baseline first so the other side does not read it backwards — especially whether "this is what is new relative to production" or "this is what was removed relative to production", which are opposite conclusions.


One small reminder: diff only presents the difference, it does not explain it. After seeing red and green lines, still judge with business context whether this change should ship — for instance whether the deleted line is a route some service still depends on. The tool is the eye; the decision is in your hands.