Compare text line differences

It works well for configuration files, logs, lists, drafts, generated output, and other material where line boundaries carry meaning. The structured response includes line numbers where they exist and a compact summary, making the result easy for both people and automated workflows to inspect.

Prepare the two versions for a useful comparison

Put the baseline version in the original field and the version you want to inspect in the revised field. The comparison treats each newline as a meaningful boundary, so preserve the formatting that matters to your task. A sentence moved onto a different line is therefore reported as a removal and an addition, even if its words have not changed. Windows and classic Mac line endings are normalized before comparison, which keeps identical content from appearing different merely because it came from another operating system. Spaces, capitalization, punctuation, and blank lines are otherwise significant. That strict behavior is useful for configuration files, generated reports, inventories, and source material where invisible formatting changes may matter. Either version may be empty when you want to show that all lines were introduced or deleted. If both versions are empty, there is nothing to compare and the request returns an input error. For predictable results, send strings directly rather than pre-tokenized arrays or objects. The service does not rewrite, trim, or interpret your content before it computes the line alignment.

Read the ordered line-by-line result

The response contains an ordered lines array followed by a summary. Every entry has a status and the exact text of that line. An unchanged entry includes both original_line and revised_line because the line exists in both versions. A removed entry includes only original_line, while an added entry includes only revised_line. These one-based positions correspond to the text that supplied the line, so they can be displayed directly in a review interface or cited in an automated report. When one line is replaced by another, the result normally contains a removed entry and an added entry; replacement is not a separate status. The summary counts added, removed, and unchanged entries, giving callers a quick way to decide whether further review is needed. Matching is based on a longest common subsequence, which preserves the order of shared lines and avoids marking an entire document as changed after a small insertion. Repeated identical lines can admit more than one mathematically valid alignment, so the algorithm uses a stable removal-first tie rule. The same input therefore always produces the same JSON output.

Use structured differences in reviews and automation

Line-level comparison is most valuable when another system needs to act on the answer. A deployment workflow can compare expected and observed configuration, reject a release when removed lines touch protected settings, and retain the structured result as evidence. A publishing system can show reviewers only additions and removals while still keeping unchanged lines available for context. A monitoring job can compare consecutive text snapshots, look at the summary first, and skip notifications when every line is unchanged. The capability is deterministic, uses no network service, and does not depend on a language model, so content is never paraphrased and repeated calls behave consistently. API requests cost $0.002; the page can also run the same pure comparison logic in the browser. Remember that this is deliberately a line comparison rather than a semantic review. It does not explain why wording changed, ignore whitespace, detect moved blocks as moves, or compare individual words inside a changed line. Choose meaningful line boundaries before sending the texts, and use the returned positions and statuses as building blocks for highlighting, auditing, testing, or alerting in your own application.