Text Comparison and Diff
Comparing two texts is not just flagging different lines against equal ones: it is finding the SMALLEST possible set of insertions and deletions that turns one text into the other, and that smallest set has a named algorithm with known cost limits.
The unified format marks the unchanged line with a space, the removed one with `-` and the added one with `+`; here the `const nome` line drops out of the change header because it stays identical on both sides.
The similarity is not "1 line equal out of 3", which would give 33%; it also counts the still-identical spans inside the changed lines, like `console.log(nome` which repeats across both versions.
With character-level granularity, swapping "gato" for "gata" isolates only the final letter instead of flagging the whole word as changed; on this pair, the similarity climbs to 84.6%.
Yes, and it goes further. The base comparison is by line, but inside each changed line you can ask for word-level or character-level highlighting, which shows exactly the term that changed instead of marking the whole line.
The Myers algorithm (1986), the same one `git diff` uses under the hood; it guarantees the smallest possible set of added and removed lines to turn one text into the other, not an approximation.
Because the internal word or character highlight, which is what keeps a single swapped comma from tanking the whole line’s similarity, only runs when the changed line pair adds up to under 20,000 characters; above that, the whole line counts as fully different.
It means the compared range was too large and had no anchor line (a line appearing exactly once on both sides) to break the problem down, so that chunk became one whole replaced block instead of the smallest possible set of changes.
Yes, local uploads accept up to 4 MB (4,194,304 bytes) per file; larger files need to be split into chunks before comparing.
Comparison, file reading and export all run in your browser. No content is sent to a server.