Developer tools · Text comparison
What a Line-Based Text Diff Will Not Do, and Why That Is Deliberate
· Why it matters
text-diff tool-selection developer-workflow
Walks through the documented limits of a single-purpose comparison tool, from no move detection to no rich text and no merging, and explains why each omission is a design choice rather than a gap.
The feature request that would break the tool — opens with a plausible request (compare .docx files with formatting) and why it changes the product
“Compare two `.docx` files with formatting and comments” sounds adjacent to text comparison, but it changes the input model, parser, output and privacy surface. ToolAcre’s route deliberately accepts two strings and computes line rows. It does not open rich-document packages.
Knowing that boundary saves time. Export plain text when wording alone matters, or choose a document-aware reviewer when layout, tracked changes, comments and metadata are evidence. Forcing either task into the other tool discards information before review begins.
Limitations as part of the product — explains ToolAcre's stance that each tool page documents what it cannot do and why
The config describes line-by-line comparison with optional case and whitespace insensitivity and collapsed unchanged regions. Source adds concrete limits: three row types, a bounded LCS table and patch-shaped text output. Those facts define the product more reliably than a broad “diff” label.
This repository does not establish a universal philosophy for every ToolAcre page, so the article avoids attributing one. The useful lesson is local: read a tool’s record and implementation before assuming features from another application that uses similar vocabulary.
The repository establishes this tool’s boundaries, not a universal ToolAcre product doctrine
There is no rich-text model. Bold, color, table geometry, footnotes and comments disappear unless represented as literal plain text. HTML entered into an editor is rendered as text in result rows, not interpreted into a visual document comparison.
That behavior is predictable and safe from accidental markup execution in the result, but it cannot tell whether two pages look the same. Use an HTML renderer, document comparator or visual regression system when presentation is the property under test.
No move detection or merging — covers why labelling moved blocks and resolving conflicts belong to version control, not a two-text comparison
There is no moved-block row, merge engine or conflict resolution. Reordered text can appear removed and added. Two-way comparison offers no common ancestor from which to distinguish independent changes, and the UI exposes no command that chooses one side as the merged result.
Download patch serializes row markers; it does not apply them. Swap sides reverses the perspective and recomputes. Those operations support inspection, but version control or a three-way merge tool must handle history, conflicts and final integration.
No server, therefore no history — explains that nothing is stored between visits, which means no saved comparisons but also nothing to delete
The reviewed UI holds the latest result in a local variable until clear or page lifecycle ends. It contains no comparison-history database, account call or browser-storage write. This means the feature exposes no saved-comparison interface in source.
Do not turn that into an absolute claim about every browser component. Form restoration, extensions and deployed scripts require runtime inspection. The defensible statement is that the Text diff implementation itself has no persistence mechanism or server processing call.
No saved history appears in the reviewed path; broader storage claims require runtime evidence
A quick suitability check has four questions: are both inputs plain text, are line-level additions and removals enough, can the differing middle fit the 2,000-line-per-side cap, and is no semantic or merge decision required? If yes, the route fits its documented shape.
If one answer is no, choose another tool before copying data. That ten-second boundary review prevents later disappointment and avoids disclosing material to a workflow that cannot preserve the evidence you need, such as comments or table relationships.
What this post does not cover — the internals of the diff algorithm or a feature-by-feature comparison of competing products
This article does not derive the algorithm’s history or compare competitors. It stays with repository-proven behavior. It also does not promise word highlighting, binary comparison, syntax validation, file loading, exact byte equality or locale-aware text equivalence.
Each omission corresponds to a different problem definition. A narrow comparator can remain understandable because it does not quietly make parsing or normalization decisions on the user’s behalf beyond its explicit line, case and whitespace rules.
Takeaway: choose tools by their honest edges — summarises how a narrow tool with clear limits, like ToolAcre's Text comparison, is easier to trust than a broad one
Choose a tool by its honest edges. Text diff is strong when two plain-text states need a transparent line account inside the browser. Its original rows, line numbers and summary make that account easy to audit, while its refusal protects the tab from an oversized differing matrix.
Use richer systems when the task needs richer evidence. A limitation is valuable information before work begins, not a defect to conceal. Matching the question to the tool produces a smaller, safer workflow and a conclusion that does not exceed what the output proves.