Skip to content
yutils
Example

Input (left vs right)

Left:
first line
second line
third line

Right:
first line
second line modified
third line

Output (line-based diff)

  first line
- second line
+ second line modified
  third line

Note

Default is line-based diff. Even small changes within a line show as `-` then `+`. Toggle between split (side-by-side) and unified (inline) views.

Usage / FAQ

When to use

  • Compare two versions of a config file, log, or email quickly
  • Place two AI outputs side by side and inspect differences
  • Self-review your own changes before a code review
  • Verify translation consistency between drafts
  • Toggle split vs unified view depending on what's easier to read

FAQ

Q.Are whitespace and newlines counted as differences?
A.Yes. Line-based diff means trailing spaces and CRLF vs LF show up. Trim the input first if you want them ignored.
Q.Can I get a word- or character-level diff?
A.This tool uses line granularity. For finer diffs, compare a single line, or use json-diff for structured JSON values.
Q.What about very large texts?
A.Thousands of lines work fine. Multi-megabyte input is not recommended since processing happens in the browser.
Fun facts
  • The 'minimum edit distance' problem was first solved in 1974 by Wagner–Fischer (O(mn) DP). Myers's 1986 O(ND) algorithm was the practical leap and became `git diff`'s default — its speed advantage shines when inputs are similar.

    Wikipedia — Edit distance
  • Diff is fast on small changes (typical code review) because the LCS (Longest Common Subsequence) is long and the changes are small. Two wholly different documents can degrade to O(N²); git's `--patience` option exists precisely for that pathological case.

    git — diff options
  • Diff units can be lines, words, or characters. Code diff is line-based; document diff (Google Docs, VS Code's inline diff) is word-based; precise analysis (DNA, NLP) is character-based — same algorithm, different token granularity.

    Wikipedia — diff algorithm