Search DevTools

Jump to any tool or page

Text Diff Viewer

Compare two blocks of text and see exactly what changed. Line, word, or character level.

Original

Changed

Differences

Paste text into both panes to see the differences.

Data Transformation

About Text Diff Viewer

Compare two blocks of text and see insertions, deletions, and changes highlighted side by side or inline. Most confusing diffs are not really about content: invisible differences in line endings, trailing whitespace, or Unicode normalisation make two visually identical files register as entirely different to a comparison algorithm.

Related Data Transformation tools

JSON FormatterImage to JSONPII RedactorSheet to JSONJSON to CSV/XLSX

Frequently asked questions

Why does a file look identical but show every line as changed?
Line endings, almost always. Windows terminates lines with CRLF and Unix with LF, and since the carriage return is part of the line's bytes, every single line differs. Nothing is visible on screen. The same happens after a file passes through a tool that rewrites endings — git's autocrlf setting is a common culprit. A trailing whitespace change produces the same effect on individual lines. Enabling whitespace-insensitive comparison confirms the diagnosis immediately.
What is the difference between line-level and word-level diffing?
Line-level treats each line as an atomic unit, so changing one character marks the whole line as replaced. That is fast and ideal for code, where line boundaries are meaningful. Word-level tokenises further and highlights just the changed span, which suits prose — a reflowed paragraph shows as one moved word rather than several rewritten lines. Character-level goes finer still but produces noisy, scattered highlights on anything longer than a short string. Most viewers combine both: lines first, words within changed lines.
How does the underlying algorithm decide what counts as a change?
Most diff tools implement Myers' algorithm, which finds the shortest edit script — the minimum number of insertions and deletions transforming one sequence into the other. It has no concept of a move: relocating a function appears as a deletion in one place and an unrelated insertion in another. Nor does it understand intent, so it may pair up lines that merely share indentation or a closing brace, producing the misaligned hunks you see when a block is wrapped in a new conditional.
Why do two strings that look the same still differ?
Unicode offers multiple encodings for the same visible character. An accented e can be a single precomposed codepoint or a plain e followed by a combining accent, and they render identically while comparing unequal. macOS and Linux normalise filenames differently, so text copied across systems can shift form. Non-breaking spaces, zero-width joiners, and directional marks are entirely invisible yet count as content. Normalising both inputs to NFC before comparison removes the first class of these surprises.
How should I read a three-way merge conflict?
A conflict marks a region both sides changed relative to a shared ancestor. The block between <<<<<<< and ======= is your version, and between ======= and >>>>>>> is theirs. What is missing from the default view is the ancestor, which is what makes conflicts hard to resolve — you cannot tell who changed what without it. The diff3 conflict style adds a ||||||| section containing the original, turning an ambiguous choice between two versions into two readable diffs.