Comparador de Texto

A line-level diff treats each newline-delimited row as the smallest unit of comparison. It marks entire lines as added, removed, or unchanged. This is the format produced by git diff and displayed in pull request reviews on GitHub and GitLab. It is optimized for code review workflows where developers think in terms of logical lines — a function signature, a return statement, a configuration value — and need to scan changes quickly across hundreds of files. The vertical layout maps to how code is written and reasoned about. A character-level diff, sometimes called an intraline diff, drills into each changed line and highlights the specific bytes, characters, or words that differ. It shows you that a line changed from 'authentication_timeout = 30' to 'authentication_timeout = 300' — a single inserted zero that a line-level diff would only flag as 'this line changed.' Character-level analysis is superior for prose review, legal document comparison, and catching typos in configuration values where the change is intentionally small. Our tool displays line-level differences by default, which gives you the broadest view immediately. Within each changed line, a word-level highlight layer marks the internal changes using a secondary color. You can toggle between word-level and character-level intraline highlighting depending on how granular your review needs to be. For contract redlining, character-level highlighting is essential — a single changed word in a clause can shift legal meaning entirely. Practical tip: use line-level diff for code, word-level for prose, and character-level for contracts and configuration files.

The diff algorithm treats input as a sequence of text tokens regardless of format, so it produces meaningful output for source code, prose, JSON, YAML, TOML, XML, CSV, SQL, log files, chat exports, configuration files, and free-form notes. The underlying Myers' algorithm computes the shortest edit script — the minimum number of insertions and deletions needed to transform one text into the other — which is a format-agnostic operation. That said, you get better results for structured formats when you normalize them first. For JSON, run both inputs through a JSON prettifier before pasting. Prettified JSON puts each key-value pair on its own line with consistent indentation. Without this step, a diff between a minified and a prettified version of the same JSON flags every character as changed, which is technically correct but practically useless. For YAML, standardize indentation depth and quote style first. For SQL, format both queries with consistent keyword casing and line breaks. For code, if the two versions have been reformatted by a different linter, run the same linter on both sides before diffing to isolate logical changes from formatting changes. Most diffs between staging and production configurations fail to reveal the real difference because one side is formatted and the other is not. Our tool offers a 'normalize whitespace' toggle that strips leading and trailing spaces and collapses internal whitespace to a single space. Practical tip: for JSON API response comparison, prettify both payloads in the JSON Formatter tool first, then paste into the diff side by side.

The entire diff computation runs in your browser using a JavaScript implementation of Myers' diff algorithm. No text is transmitted to any server at any point during the process. When you click Compare, the algorithm executes locally in your browser's JavaScript engine and produces the highlighted result in memory. No API request is made, no log entry is created, and no analytics event carries your input content. This architecture was chosen intentionally to make the tool safe for sensitive material. Legal contracts, employment agreements, and settlement negotiations frequently need comparison without triggering confidentiality obligations. Private source code under a closed-source license cannot be uploaded to third-party servers without the owner's consent. Medical records, patient histories, and clinical notes are governed by HIPAA and GDPR, which restrict transmission to external services. Financial documents, term sheets, and regulatory filings are subject to strict information barrier rules. For all of these categories, a browser-only diff tool is the only compliant option. The tool also functions offline after the initial page load. If you disconnect your network connection, all diff functionality continues to work. You can verify the network isolation yourself by opening Developer Tools, selecting the Network tab, and clicking Compare. No outbound requests will appear in the log. For very large inputs — documents with tens of thousands of lines — Myers' algorithm has worst-case complexity proportional to the square of the input size, so comparison may take several seconds. Practical tip: split very long documents into sections before diffing to keep response time under two seconds.

Yes. The tool produces three export formats, each designed for a different downstream use. The first is unified diff — the standard text format that git and the Unix patch command understand. It uses @@ hunk markers to indicate line ranges, a plus sign prefix on added lines, a minus sign prefix on removed lines, and unmarked lines for unchanged context. A unified diff file can be applied directly to the original document using the command patch -p0 < changes.diff. Use this format when you need to distribute changes to be applied programmatically rather than reviewed visually. The second format is side-by-side HTML. This is a self-contained HTML file with inline CSS that renders the original and modified texts in parallel columns with color-coded additions and deletions. It opens in any modern browser with no plugins, no external dependencies, and no internet connection required. Use this format for design reviews, client sign-off meetings, and documentation archives where the reader needs to see both versions simultaneously. The third format is a plain-text summary listing all added lines and all removed lines as two labeled groups. This suits change logs, meeting notes, and audit trails where the reader needs a summary rather than line-by-line navigation. All three formats are built in your browser's memory and downloaded as local files. No content is uploaded during generation. Practical tip: use the unified diff format when handing off editorial changes to a developer who will apply them to a template file using patch.