Compare bounded text or code revisions locally with exact line hunks or Unicode code-point highlights. Line mode produces side-by-side change blocks and a unified patch, preserves missing-final-newline evidence, and can ignore line-edge whitespace explicitly. Character mode reports half-open UTF-16 ranges without normalizing source text; files remain local, oversized comparisons fail visibly, and a matching view is not presented as semantic code review.
Continue with a related workflow or open the next tool that usually follows this task.
Use a case converter to draft names, then treat every rename as a contract change: inventory consumers, define acronym rules, review invalid identifiers, compare a diff, and verify the destination.
OpenRelated toolFormat, minify, and syntax-check eight code and data languages locally with parser-specific engines.
OpenRelated toolCount original CRLF, LF, CR, and Unicode line separators in a local file.
OpenRelated toolTest bounded JavaScript regex in a worker with capture ranges, highlights, and a one-second timeout.
OpenPaste or load the original text on the left and the revised text on the right; either side may be empty for a new or deleted file.
Choose Line for source files, configuration, and patches, or Character for a bounded inline wording change.
In Line mode, choose 0, 3, 5, or 10 context lines and enable only the CRLF or line-edge-whitespace equivalence you intend to review.
Run the comparison explicitly, then check raw additions, raw removals, paired display replacements, and hunk count before reading individual rows.
Inspect missing-final-newline markers and switch to Unified patch when an exact unfiltered line result needs to be copied or downloaded.
Verify the patch against the source file and rerun without filters before applying changes in a repository, deployment, or archival workflow.
Compare a proposed source file with its previous version and export an unfiltered unified patch for independent review.
Find changed ports, feature flags, endpoints, and environment values while keeping surrounding configuration lines visible.
Use code-point highlights to locate a small insertion, deletion, punctuation change, or altered identifier inside bounded text.
Distinguish real content edits from CRLF/LF or line-edge whitespace noise, then rerun without filters before making a patch.
Compare generated manifests, logs, query results, or fixture snapshots without sending their contents to a comparison server.
Ignoring line-edge whitespace or stripping CR before LF changes the equality rule. A filtered result is useful for review, but its patch can omit byte-level differences and should not be treated as an exact transformation of the original files.
Line mode detects inserted and removed lines; character mode detects inserted and removed Unicode code points. Comparing by visual position makes one insertion look like every following token changed.
A grapheme such as a family emoji, flag, accented sequence, or emoji joined with U+200D can contain several Unicode code points. Character highlights are not guaranteed to match what a reader perceives as one character.
A final newline is part of a text file's structure. The patch marker and the result facts distinguish `alpha` from `alpha `; do not dismiss that evidence when scripts, POSIX tools, or repository checks require a terminator.
The browser limits each side to 2 MiB, line mode to 100,000 lines, character mode to 100,000 code points, and difficult comparisons by time and edit distance. Split large unrelated files instead of assuming a timeout means equality.
Two adjacent configuration lines are replacements and one endpoint is inserted. Raw patch counts remain three additions and two removals; two rows are paired only to make the side-by-side review easier to scan.
Before (ends with newline):
server:
port: 8080
log: info
routes:
- /health
After (ends with newline):
server:
port: 8081
log: debug
routes:
- /health
- /ready
Added patch lines: 3 | Removed patch lines: 2 | Paired replacement rows: 2 | Unified patch includes - port: 8080, + port: 8081, and + - /readyThe emoji is one code point here, and inserting X does not make B and C appear modified. The unchanged count includes A, the emoji, B, and C.
Before: A😀BC
After: A😀XBCAdded code points: 1 | Removed code points: 0 | Unchanged code points: 4 | Change groups: 1Line mode uses jsdiff 9 structuredPatch(), which runs the library's Myers-family shortest-edit implementation over line tokens. Context length changes only how much unchanged material appears around a hunk; it does not alter which lines compare equal.
Raw added and removed counts come directly from '+' and '-' patch lines. A contiguous removal block and addition block are paired by position for the side-by-side modified-row display. Those paired rows are a visual alignment aid, while the unified patch retains the independent additions and removals.
Ignore line-edge whitespace maps to jsdiff's ignoreWhitespace option, which trims each line only for equality. Treat CRLF as LF maps to stripTrailingCr, which removes one CR immediately before LF. Neither option mutates the text fields.
Unified output names the inputs before.txt and after.txt, emits standard file headers and hunk ranges, and retains the `\ No newline at end of file` marker. Filtering options can make that output unsuitable as an exact patch because intentionally ignored differences are absent.
Character mode uses diffChars(), where a character is a Unicode code point rather than a UTF-16 code unit. It aligns shifted content correctly, but does not segment extended grapheme clusters; a visible emoji or accented letter can contain multiple compared units.
Each side is limited to 2 MiB of UTF-8. Line mode allows at most 100,000 line tokens, character mode at most 100,000 code points, computation is bounded to 1,500 ms and edit distance 20,000, line previews to 2,000 rows, and character previews to 50,000 displayed code points. Exceeding a computation budget produces an error, never a fabricated whole-file replacement.
Line mode tokenizes complete lines, groups edits into hunks, shows context, and can export unified diff text. Character mode tokenizes Unicode code points and highlights inline insertions or deletions in two panels; it does not create a line patch.
It trims leading and trailing whitespace when deciding whether two lines are equal. It does not remove spaces inside a line, and it does not mean all whitespace everywhere is ignored.
The option removes the carriage return directly before each line feed for comparison, making CRLF and LF lines equal. Lone CR characters are not advertised as normalized, and the original input text is not rewritten.
With both filtering options off, the unified patch records the exact line comparison, including missing-final-newline markers. With either filter on, the patch represents the filtered review and can omit source differences, so verify it before applying.
The implementation uses jsdiff 9's Myers-family shortest-edit algorithm with explicit time and edit-distance budgets. Side-by-side replacement rows pair adjacent removals and additions by position for display; that pairing is not a semantic claim that two lines mean the same thing.
No. Character mode follows Unicode code points, the units produced by JavaScript string iteration. Combining marks, regional indicators, variation selectors, and ZWJ emoji sequences can be split into multiple highlighted units.
Comparison, preview construction, patch generation, copy, and download happen in this browser. Files are read with the browser FileReader API. Aggregate analytics can record mode, counts, limits, and timing, but not the pasted text, file contents, or patch body.
Maintained and tested by SimpleWebUtilsReviewed
Method: In Diff Checker for Text, Code, and Unified Patches, the “Review a configuration change before preparing a patch” fixture was run without repairing or simplifying its input. We verified the transition from “Create an exact line baseline” to “Diagnose line-ending and edge-whitespace noise”, compared the final artifact or values, and reviewed “Counting a visual replacement once” plus “Treating indentation as cosmetic everywhere” as non-success paths.
Expected result: The comparison reported three added patch lines, two removed patch lines, two paired replacements, and one hunk, with the port, log level, and /ready route changes visible in the exported patch.
Open the tested workflowUse these focused guides when you need a practical workflow before opening the tool.
Use a case converter to draft names, then treat every rename as a contract change: inventory consumers, define acronym rules, review invalid identifiers, compare a diff, and verify the destination.
Workflow guideFormatting and minification should produce reviewable, reproducible artifacts, not hide syntax errors or change data tokens. This workflow classifies the source and destination first, removes secrets, runs a language-specific parser, records exact settings and byte changes, compares semantic boundaries, and verifies the candidate in the real browser, compiler, loader, schema, and test suite before replacing the original.
Workflow guideA useful diff workflow starts with exact input, not filters. Preserve the source files, compare line structure and final newlines, explain every raw addition and removal, use equivalence options only as a diagnostic view, and validate any exported patch against a disposable copy before it reaches a repository or deployment.
Workflow guideHTML-to-JSX conversion removes repetitive syntax work, but migration quality depends on what happens afterward. This workflow records the original behavior, limits the conversion to one coherent fragment, compares browser-normalized structure, rewrites legacy events and URLs, moves styles and assets into the destination project, and finishes with lint, type, accessibility, responsive, and security checks. The generated JSX is treated as reviewable source, not as a sanitized or complete component.
Workflow guideHTML-to-Markdown conversion can remove repetitive rewriting, but a publishable migration also needs content isolation, trust-boundary review, asset relocation, and a real destination preview. This workflow converts one article or documentation section, checks every removed or preserved structure, replaces unsafe links and interactive controls, moves images, and verifies the finished file with the renderer that will actually publish it.
Workflow guideHTML-to-Pug conversion removes repetitive tag rewriting, but a dependable migration also needs a source baseline, dependency inventory, active-code redesign, explicit template locals, and tests in the destination application. This workflow converts one coherent view, checks browser normalization and preserved events or URLs, moves page dependencies, adds only the Pug logic the application needs, and verifies the compiled HTML rather than approving a file because its syntax parses.
Workflow guideA slug generator can produce a consistent path-segment candidate, but it cannot own the route or protect a published address. This workflow records the target platform and current URLs, chooses an explicit Unicode or ASCII convention, reviews transliteration and encoded length, checks duplicates and reserved names in the real namespace, and treats redirects, canonical metadata, internal references, sitemap updates, monitoring, and rollback as required parts of any live URL change.
Workflow guideSQL formatting can expose joins, predicates, grouping, and subqueries, but readable output is not evidence that a statement is valid or safe. This workflow identifies the target database and version, preserves and redacts the source, applies one explicit formatter grammar, reviews exact token and comment changes, and then verifies schema resolution, permissions, result sets, plans, transactions, migrations, tests, and rollback in the real toolchain.
Workflow guideUse this workflow when an editor, researcher, support team, or SEO review asks whether a draft repeats words, contains a target phrase too often, reads easily, sounds negative, or resembles another version. It records the unit, language, normalization, denominator, limits, and interpretation before analysis, then separates deterministic evidence from editorial judgment.
Workflow guideA safe bulk-replacement workflow starts with an untouched source and the narrowest matching rule. It proves patterns separately, makes every flag and dollar token explicit, reviews boundary and zero-width diagnostics, compares the exact output, and tests the destination instead of treating a replacement count as correctness.
Workflow guideUse this workflow when a test, mockup, terminal demo, documentation example, or harmless visual experiment needs generated or rearranged text. It separates structural operations from decoration, preserves source and separator behavior, records every seed and limit, and requires a plain-text alternative whenever FIGlet, mirror, upside-down, Braille-subset, or Zalgo output may not survive fonts, assistive technology, search, or copying.
Workflow guideA reliable Unicode-normalization workflow preserves the original representation, confirms the target system's contract, distinguishes canonical normalization from compatibility folding, inspects exact code points and hidden characters, compares the result, and validates the completed value where it will be stored or matched.
Workflow guideUse this workflow when two values look identical but compare, search, wrap, parse, or render differently. Map supported controls before editing, distinguish common hidden separators from joining and line-break controls, retain exact line endings and normalization, and record why each removal was safe.
Continue with another maintained workflow
Format, minify, and syntax-check eight code and data languages locally with parser-specific engines.
Count original CRLF, LF, CR, and Unicode line separators in a local file.
Test bounded JavaScript regex in a worker with capture ranges, highlights, and a one-second timeout.
Number, filter, sort, split, merge, trim, and wrap text locally in one repeatable workspace.
Replace literal or regex matches with Unicode boundaries, capture tokens, exact counts, and Worker limits.