File & Text Diff Checker

About File & Text Comparison

Spotting what changed between two versions of a file by eye is slow and unreliable, especially across long documents, source files, logs, or configuration exports. A diff checker compares the two inputs line by line using a longest-common-subsequence algorithm — the same core technique behind git diff and code-review tools — then reports exactly which lines were added, which were removed, and which were modified. This makes it easy to review edits, audit config drift, verify exports, or confirm what a change actually touched.

How to Read the Diff:

• Added (+): Lines present in the right (changed) input but not in the left (original).
• Removed (-): Lines present in the left input but missing from the right.
• Changed (~): In the side-by-side view, a removed line paired with an added line at the same position — shown side by side so you can compare the old and new text directly.
• Unchanged: Identical lines, dimmed for context so you can see where changes sit within the file.

Options:

• Ignore case: Treats ERROR and error as the same line.
• Ignore whitespace: Collapses runs of spaces and trims each line, so re-indentation or trailing spaces are not flagged as changes.

Common Use Cases:

• Config Review: See exactly what changed between two versions of a settings or environment file.
• Log Analysis: Compare log output before and after a change to isolate new errors.
• Content Editing: Track edits between two drafts of an article, contract, or document.
• Code Review: Compare two versions of a script or source file without a full version-control setup.

Choosing a View

• Side-by-side is best for prose and for changed lines, because you can read the old and new text against each other. It needs screen width.
• Unified is the format Git and code review use — compact, works on a narrow screen, and easy to paste into a ticket or a chat message.
• Changes only strips the unchanged context. Use it on long files where three real edits are buried in two thousand identical lines.

When the Diff Is Noisier Than the Change

A line-based diff reports a line as changed if a single character on it differs, which produces some predictable false noise:

• Line endings. A file saved on Windows (CRLF) diffed against the same file saved on Linux (LF) can report every line as changed. If everything is flagged and nothing looks different, this is almost always why — normalise the endings first.
• Reformatting. A formatter run, an indentation change, or a re-wrapped paragraph rewrites lines without changing meaning. Turn on ignore whitespace to see past it.
• Trailing newline. A missing final newline shows as a change to the last line even when its text is identical.
• Moved blocks. A line-based diff has no concept of a move: relocated content appears as a deletion in one place and an unrelated addition in another.
• Long single-line files. Minified JavaScript or a one-line JSON payload is a single line, so a line diff can only tell you it changed. Pretty-print it first — for JSON, the JSON Formatter does exactly this.

Line Diff or Structural Diff?

Use this tool for anything line-oriented: YAML, .env files, nginx and Apache configs, CSV exports, log excerpts, Markdown, source files, SQL dumps, Terraform plans. Reach for the JSON Diff Checker instead when both sides are JSON — it compares by key rather than by line, so it is not fooled by reordered keys or differing indentation, and it reports differences as paths into the document rather than as line numbers.

Privacy

Files are read with the browser's FileReader and compared in the page. Nothing is uploaded, stored, or tracked. That is the difference that matters for the things people actually diff — .env files, production configs, contracts, and log excerpts containing customer data — none of which belong in a server-backed diff tool.