Diff Checker — Compare Text Word by Word
Compare two texts with changes highlighted inline at word level, so a reflowed paragraph does not show up as a wholesale rewrite.
Line, word and character diffs
Every diff algorithm has to choose a unit of comparison, and the choice determines what the output is useful for.
Line-level is what git diff does by default. It is ideal for code, where lines are meaningful units and a change usually is a whole line. Its failure mode is prose: change one word in a paragraph that is stored as a single long line and the entire paragraph shows as deleted and re-added.
Word-level — what this tool uses — splits on whitespace, so a one-word edit highlights one word. That makes it far better for prose, configuration values, and any text that has been reflowed. It also handles the case where a code change moves a line's content around without changing much of it.
Character-level is the finest grain and is genuinely useful for short strings: spotting that an API key differs in one character, or that two URLs differ by a single letter. On longer text it produces noise — highlighting fragments inside words that are simply different words.
Underneath, most diff tools implement a variant of the Myers algorithm, which finds the shortest edit script between two sequences. It is optimal in the sense of minimising the number of changes, which is not always the same as producing the most human-readable result — hence the various heuristics real tools layer on top.
When two identical-looking texts differ
Nearly every "the diff is wrong" report turns out to be one of these. All are invisible on screen:
Whole file shows as changed, no visible difference
Cause:Line endings. Windows uses CRLF (\r\n), Unix and macOS use LF (\n). Every line differs by one invisible character.
Fix:Normalise before comparing. In git, configure core.autocrlf, or add a .gitattributes with `* text=auto` to stop the problem recurring.
One line differs but looks identical
Cause:Trailing whitespace — spaces or tabs after the last visible character.
Fix:Enable "show invisibles" in your editor and turn on trim-on-save. Most linters can enforce this.
Indentation differs but both look aligned
Cause:Tabs on one side, spaces on the other. They render the same at the right tab width.
Fix:Pick one and enforce it with an .editorconfig file. Which one matters far less than consistency.
A word differs but the characters look the same
Cause:A non-breaking space (U+00A0) instead of a normal space, or a curly quote instead of a straight one. Both arrive when text is pasted from a browser, Word or Google Docs.
Fix:Search for U+00A0 specifically. Smart-quote substitution is the other frequent culprit and breaks code silently.
Two visually identical strings compare unequal
Cause:Unicode normalisation. é can be one code point (U+00E9) or two (e + U+0301). macOS filesystems historically produced the decomposed form, most other sources the composed one.
Fix:Normalise both sides with NFC before comparing: `str.normalize("NFC")` in JavaScript, `unicodedata.normalize("NFC", s)` in Python.
A file has an invisible character at the very start
Cause:A UTF-8 byte order mark (EF BB BF). Some Windows editors add it on save.
Fix:Save as "UTF-8 without BOM". A BOM also breaks JSON parsing and can produce stray output before PHP headers.
What people actually use this for
- Config drift —Comparing a working environment’s config against a broken one. Usually the fastest route to the cause of "it works in staging".
- API response changes —Diffing two responses to see exactly what a provider changed between versions. Sort object keys first, or key reordering swamps the real differences.
- Reviewing edited prose —Seeing precisely what a copy edit changed, where word-level granularity matters most.
- Verifying a copy or migration —Confirming that generated output matches an expected fixture, character for character.
- Comparing dependency trees —Two lockfiles or `pip freeze` outputs, to find the package that changed between a passing and failing build.
About
The Diff Checker compares two blocks of text or code and shows every difference in real time — no submit button required. Paste into the Original and Modified panels and differences appear immediately, colour-coded by type: lines added in green, removed in red, and modified lines in amber with character-level inline highlighting that pinpoints exactly which characters within a line changed. This character-level precision is what separates this tool from most online diff checkers, which only highlight entire lines. Two viewing modes are available. Split view places Original and Modified side-by-side with line numbers aligned, making it easy to read changes in context. Unified view mirrors the format used by git diff and patch files, with + and − prefixes and line numbers for both sides. The "Collapse unchanged" toggle hides unmodified lines (showing only three lines of context around each changed region) to bring the signal-to-noise ratio down to what matters — just like GitHub pull request diffs. Two normalisation options — Ignore Whitespace and Ignore Case — let you focus on semantic changes rather than formatting differences. The "Copy diff" button exports a standards-compliant unified diff string you can paste directly into a patch file or code review. File upload supports text, source code, JSON, YAML, Markdown, SQL, and more. All processing runs in your browser using a custom LCS algorithm — no data is sent anywhere.
How to use
- 1 Paste or type the original text into the left (Original) panel.
- 2 Paste or type the modified text into the right (Modified) panel — the diff appears immediately.
- 3 Use Split view to compare side-by-side, or Unified view for a git-style diff with + and − prefixes.
- 4 Enable "Collapse unchanged" to hide unmodified lines and focus only on what changed.
- 5 Toggle "Ignore whitespace" or "Ignore case" to suppress formatting-only or case-only differences.
- 6 Click "Copy diff" to copy a git-compatible unified diff string to your clipboard.
- 7 Click the Upload button on either panel to load a text or source-code file directly from your device.
- 8 Use the Swap button to reverse Original and Modified to see the inverse diff.
- What is character-level inline highlighting?
- Most diff tools only highlight entire lines as added or removed. This tool goes further: for lines that were modified (not wholesale added or removed), it runs a second diff on the individual characters within that line. The exact characters that changed are highlighted in a darker shade, making it easy to spot a renamed variable, a changed value, or a corrected typo without reading the entire line.
- What is the difference between Split and Unified views?
- Split view shows the Original text on the left and Modified text on the right, with line numbers aligned so matching lines appear at the same height. Unified view mirrors the format produced by "git diff" — both sides are shown in a single column with "−" prefixes on removed lines and "+" prefixes on added lines. Unified view is more compact; split view is easier to read when many lines change on both sides simultaneously.
- What does Collapse Unchanged do?
- When enabled, lines that are identical in both versions are hidden, showing only three lines of context around each changed region (just like GitHub or GitLab pull request views). This makes large files much easier to review by removing noise. Click the "X unchanged lines hidden" bar to expand any collapsed section.
- Is there a file size limit?
- File uploads are limited to 2 MB per side. There is no hard limit on pasted text, but the diff algorithm is O(nm) in the worst case so very large files (tens of thousands of lines) may take a moment to compute. Prefix/suffix optimisation means files that share most of their content compute near-instantly regardless of total size.
- Is my content sent to a server?
- No. The entire diff — LCS computation, character-level analysis, unified diff generation — runs in your browser using JavaScript. Nothing is ever transmitted to CodeLint.Dev servers or any third party. This makes it safe to paste source code, configuration files, private documents, or any sensitive content.
- What file types can I upload?
- Any UTF-8 text file works: .txt, .js, .ts, .jsx, .tsx, .json, .yaml, .yml, .md, .css, .html, .xml, .py, .java, .go, .rs, .rb, .php, .sh, .sql, .csv, and more. Binary files are not supported.
The full guide
More in Developer Tools
See all developer tools.