Diff two text files

Open this example in Text Diff

Open the tool, then paste the sample input below. Everything runs locally in your browser.

The problem

Two versions of a config or a log look almost identical and you need to find the one line that differs. Scanning by eye is error-prone. A line-by-line diff highlights exactly what was added, removed, or changed.

Sample input

Version A

host=localhost
port=8080
debug=false

Version B

host=localhost
port=9090
debug=true

Expected output

Diff

  host=localhost
- port=8080
+ port=9090
- debug=false
+ debug=true

Unchanged lines are shown for context; removed lines are marked - and added lines +.

How to do it

Paste the first version on the left.
Paste the second version on the right.
Run the diff.
Read the added and removed lines.
Copy the changed lines you need.

Common mistakes

Trailing whitespace that makes identical lines look different.
Mixed line endings (CRLF vs LF) flagged as changes.
Comparing reordered lines where order is not meaningful.
Pasting only part of one file so everything after looks added.
Expecting a word-level diff when the tool compares lines.

Related tools

Related guides

Compare two CSV files by key

FAQ

How do I compare two text files?

Paste each version into one side and run the diff. The tool aligns the lines and marks what was added, removed, or unchanged.

Why are identical-looking lines marked as different?

Usually trailing whitespace or different line endings. Normalize whitespace and line endings so only real changes remain.

Does it diff line by line or word by word?

It compares line by line, marking whole lines as added or removed. That is ideal for config files and logs.

Can I compare config files?

Yes. A line diff is well suited to config and environment files, where each setting is on its own line.

Is my text uploaded?

No. The comparison runs locally in your browser. Neither file is sent to a server.

Text diffing runs locally in your browser. Your files are not uploaded.

Explore more data cleanup and QA tools

Diff text, compare CSVs, clean lists and build SQL filters — grouped in one place.

View the data cleanup & QA toolkit →

Practical example and expected result

Paste two versions of a file - config, release notes, output - and see a line-by-line diff of what changed. No upload, no install. In practice, this is most useful when you need a quick, repeatable check on a developer artifact before adding it to a ticket, pull request, test fixture, or support note.

A realistic input for this workflow is host=localhost port=8080 debug=false. The expected result should resemble host=localhost port=9090 debug=true, with the same important values preserved.

Troubleshooting checklist

Confirm you copied the complete developer artifact and not only a partial line or truncated preview.
Run the local tool once with a safe sample, then repeat with the real data only if your team policy allows it.
Check quoting, escaping, whitespace, encoding, timestamps, and environment-specific values before trusting the result.
Before sharing output, remove secrets, tokens, cookies, customer data, and production hostnames that are not needed for the review.

Next useful steps

Open this example in Text Diff → for a related validation or follow-up step.
Diff two JSON payloads for a related validation or follow-up step.
Compare two lists for a related validation or follow-up step.
Use Magic Box when you are not sure which tool should handle the next artifact.

Review checklist before sharing the result

For Diff two text files, the safest workflow is to test with a small sample, confirm the output shape, then repeat with the real artifact only when needed. Keep the original input open until you verify that no value was dropped, decoded twice, sorted unexpectedly, or changed from text into a different type.

Before copying the result into a pull request, issue, chat thread, or support ticket, scan for private values. Replace real IDs, bearer tokens, session cookies, email addresses, internal hostnames, and customer data with placeholders. If another tool is listed above, use it as the second pass rather than manually editing complex output.

Keep one line of context explaining why the transformation was needed.
Preserve enough sample structure for a reviewer to reproduce the result locally.
Note any assumptions about encoding, timezone, delimiter, schema version, or runtime environment.