Free online diff checker. Compare two files, code or config side-by-side or unified, by line, word or character. Runs in your browser; nothing is uploaded.
This diff checker compares two blocks of text, code or configuration and shows you exactly what changed — line by line, word by word, or character by character, in a side–by–side or unified view. Paste both versions, or load two files from disk, and the comparison appears as you type. It is free, needs no account, and the comparison runs entirely in your browser: the diff library and your text never leave the page, so nothing is uploaded to a server at any point.
That last property is the reason to use an in–browser diff tool for anything sensitive. Comparing two versions of a production config, a contract, a customer export or an environment file means pasting real content somewhere. On a tool that posts your input to a backend, that content becomes someone else’s log entry. Here it stays on your machine.
Most comparison pages leave you to discover the limits by hitting them. Here is the honest inventory up front.
| Capability | Supported |
|---|---|
| Compare pasted text, code, or config | Yes |
| Load two files from disk | Yes — read locally, never uploaded |
| Side–by–side (split) view | Yes, with line numbers on both panes |
| Unified view | Yes, with old and new line numbers and +/- markers |
| Line, word, and character granularity | Yes — three modes |
| Word–level highlighting inside changed lines | Yes, in split view |
| Ignore whitespace / ignore case | Yes, independent toggles |
| Change statistics (added, removed, modified, unchanged, total) | Yes |
Copy the diff, or export a .diff file | Yes |
| Swap the two sides | Yes, one click |
| Shareable permalink | Yes, for inputs up to 4 KB per side |
| Three–way merge / conflict resolution | No — two–way comparison only |
| Image, PDF, Word, or spreadsheet comparison | No — text–based formats only |
| Folder or directory comparison | No |
| Semantic JSON or XML diff (structure–aware) | No — comparison is textual; see the formatting tip below |
| Saved diff history or accounts | No — nothing is stored |
If you need image, PDF or spreadsheet comparison, or a three–way merge, this is the wrong tool and the sections below say what to use instead. For text, code and config — which is the overwhelming majority of real comparisons — it does the job without an upload.
.txt, .json, .yaml, .yml, .xml, .md, .css, .html, .sh, and source files for JavaScript, TypeScript, Python, Java, C, C++, Go, Rust, PHP and Ruby.git diff.comparison.diff; the shareable link button encodes both inputs into the URL.Two conveniences worth knowing: Swap reverses the sides in one click when you paste them the wrong way round (easily done, and it inverts every addition and removal), and Insert Sample loads a short before/after code pair so you can see how the output reads before committing your own content.
These are not cosmetic preferences — they answer different questions.
| Use split (side–by–side) when | Use unified when |
|---|---|
| You want to read both versions as documents and compare them in context | You want the changes and nothing else |
| Lines were rewritten rather than added or deleted — word–level highlighting inside a changed line only appears here | You are pasting the result into a code review, ticket, or commit message |
| You are reviewing prose or configuration where surrounding context matters | You want output that reads like git diff, with + and - markers |
| The screen is wide | The screen is narrow, or lines are long |
Unified is the format nearly every code–review tool speaks, which is why the export produces it. Split is the better reading format, because a changed line shows its before and after next to each other with the specific words that differ highlighted inside them.
| Mode | What it compares | Best for |
|---|---|---|
| Lines | Whole lines as units | Source code, config files, logs, CSV — anything where the line is the meaningful unit. The default, and correct most of the time. |
| Words | Word–separated tokens across the whole text | Prose, documentation, copy review, translations — where a sentence gets reworded and line–level output would just show the whole paragraph as changed. |
| Chars | Individual characters | Finding a one–character difference: a swapped digit in a key, a homoglyph, a stray character in an ID, an l against a 1. |
The failure mode to recognise: if line mode reports that almost everything changed, the file was probably reformatted or re–wrapped rather than rewritten. Switch to word mode, or turn on Ignore Whitespace, and the real change usually resolves to a handful of tokens.
This is the option people reach for most and understand least, because “whitespace” covers four genuinely different kinds of change:
\r\n); on Linux and macOS it is LF (\n). Every single line differs by an invisible character, so a diff shows 100% of the file as changed even though nothing was edited.Turning on Ignore Whitespace here normalises whitespace differences so the comparison reports only substantive changes. That is what you want when a formatter has run, when a file has crossed operating systems, or when someone re–indented a block. It is emphatically not what you want in Python, YAML, Makefiles, or anything where indentation is syntax — there, a whitespace change is the change, and hiding it hides a real bug.
The same distinction exists on the command line: git diff -w ignores all whitespace, git diff -b ignores changes in the amount of whitespace but not its presence, and git diff --ignore-blank-lines handles added or removed empty lines. If you are trying to keep whitespace noise out of your reviews and commits for good, our guide to ignoring whitespace and formatting differences in diffs covers the git flags, editor settings, and .gitattributes line–ending configuration that stop the noise at source rather than hiding it after the fact.
Ignore Case is the smaller sibling and follows the same logic: useful for prose, config keys, SQL keywords, and hostname comparisons; actively misleading for case–sensitive identifiers, passwords, hashes, base64 payloads, and any language where userId and userid are different symbols.
The comparison is textual, which means how you prepare the two sides determines how useful the result is. This is the step most people skip.
| What you are comparing | How to get a clean diff |
|---|---|
| Source code | Line mode, split view. Turn on Ignore Whitespace only if a formatter ran — and never for Python. |
| JSON | Pretty–print both sides with the same indentation first, otherwise a single–line document diffs as one enormous changed line. Key order also matters to a textual diff even though it does not matter to JSON — sort keys on both sides if the emitters differ. Our JSON formatter normalises both inputs before you paste them. |
| YAML | Line mode, and leave Ignore Whitespace off — indentation is structure in YAML, so hiding it hides real changes. The YAML to JSON converter is useful when you want to compare two YAML documents by structure rather than by layout. |
Config files (.env, .ini, nginx, Apache) | Line mode. Sort both sides first if the order is not meaningful — otherwise a moved block reads as a large delete plus a large add. |
| CSV and exports | Line mode with one record per line. Diffing a re–sorted export is not informative; sort both sides by the same key first. |
| SQL | Format both sides consistently before comparing — the SQL formatter makes two differently–laid–out queries comparable. |
| Prose, docs, contracts | Word mode. Line mode reports an entire reflowed paragraph as changed; word mode finds the three words that actually moved. |
| Minified or single–line files | Character mode, or format both sides first. A minified bundle has no line structure for line mode to work with. |
| Encoded payloads (base64, JWTs, tokens) | Decode both sides first — two base64 strings differ from the first changed byte onward and tell you nothing. The base64 encoder and decoder handles the decode step. |
The general rule: normalise, then diff. Almost every “this diff is useless” complaint is a formatting difference being reported faithfully.
The counters above the inputs summarise the comparison before you read a single line:
Because the modified count is derived from paired removals and additions, a rewritten line counts once as a modification rather than twice as an unrelated delete and add — which is what makes the ratio of modified to added plus removed a quick read on whether a change was a rewrite or a genuine insertion.
A two–way diff answers “what is different between A and B?” A three–way merge answers a harder question: “A and B both changed from a common ancestor — which edits can be combined automatically, and which conflict?” That requires the original base version as a third input, and it is what happens under the hood during a git merge.
This tool is two–way only and does not attempt merges. For a genuine three–way merge, use git merge-file <current> <base> <other>, the classic diff3 utility, or a dedicated merge tool such as Meld, KDiff3, Beyond Compare, or your IDE’s merge view. Where a two–way diff still helps during a merge is in inspecting a conflict after the fact: paste the two conflicting versions here to see precisely what each side did before you decide which to keep.
| Reach for | When |
|---|---|
| This browser tool | The content is not in version control — two pasted API responses, a config from one server against another, a document someone emailed you, output from two runs of a script. Also whenever the content is sensitive enough that you do not want it leaving your machine, and whenever you are on a machine where you cannot install anything. |
git diff | Both versions are commits, branches, or working–tree states in the same repository. Nothing beats it there, and it brings whitespace flags, word–diff, and rename detection with it. |
diff -u / colordiff | Both files are on the same machine and you are already in a terminal. diff -u file1 file2 produces the same unified format this tool exports. |
| Desktop merge tools | Three–way merges, whole–directory comparison, or repeatedly comparing very large files. |
The comparison runs client–side. The diff engine is loaded into the page and executes against text held in your browser’s memory; files you attach are read with the browser’s local file API rather than uploaded. There is no request carrying your content to a server, no account, and no stored history — close the tab and the comparison is gone.
This matters for the comparisons people actually run. Environment files with credentials in them. Two versions of a customer data export. A contract redline. An incident–response log. Infrastructure config that names internal hosts. Pasting any of those into a tool that round–trips through a server is a data–handling decision, whether or not it is recognised as one at the time. One caveat to state plainly: the optional shareable link feature encodes your two inputs into the URL so a colleague can open the same comparison. That is a deliberate action, it is capped at 4 KB per side, and you should not use it for sensitive content — the text travels wherever the link does.
No. The comparison runs entirely in your browser using a diff library loaded into the page, and files you attach are read locally rather than transmitted. Nothing is sent to a server, nothing is stored, and there is no account. The one exception is the shareable link, which deliberately encodes your inputs into the URL when you click it.
Click Upload File under either input box and pick a file. The browser reads its contents locally and fills the box — the file itself never leaves your machine. Do this on both sides to compare two files. Text formats are supported, including source code, JSON, YAML, XML, Markdown, HTML, CSS and shell scripts.
Split shows the two versions in parallel columns with line numbers on each, which is easier to read and is the only view with word–level highlighting inside changed lines. Unified interleaves them into a single stream with + and - markers, matching what git diff produces and what code–review tools expect.
It normalises whitespace differences so the comparison reports only substantive changes — useful after a formatter has run, when a file has moved between Windows (CRLF) and Unix (LF) line endings, or when a block has been re–indented. Do not use it on Python, YAML, or Makefiles, where indentation is syntax and a whitespace change is a real change.
Almost always an invisible character: trailing spaces, a tab where the other side has spaces, CRLF against LF line endings, a non–breaking space pasted from a document, or a Unicode homoglyph. Switch to character mode to find the exact position, or enable Ignore Whitespace to confirm whitespace is the cause.
Yes, as text — and you will get a far better result if you pretty–print both sides with the same indentation first, since a single–line JSON document otherwise diffs as one enormous changed line. Note that a textual diff also treats reordered keys as changes even though JSON considers them equivalent, so sort keys on both sides if the two documents came from different emitters.
The Export .diff button downloads the comparison in annotated unified form with + and - prefixes, which is ideal for review, tickets, and documentation. It does not emit the file headers and @@ hunk ranges that git apply or patch require, so use git diff or diff -u when you need a patch that will apply cleanly.
No — this is a two–way comparison tool. A three–way merge needs the common ancestor as a third input; use git merge-file, diff3, or a dedicated merge tool such as Meld or KDiff3. You can still paste two conflicting versions here to understand what each side changed before resolving the conflict.
It handles typical source files and configs comfortably. Because everything is computed in your browser, very large inputs — multi–megabyte logs or database dumps — are limited by your machine rather than a server quota, and character mode is far more expensive than line mode on large text. For files of that size, a local diff -u is the better tool.
Use the shareable link button and send the URL — it encodes both inputs plus your view and mode settings, so the recipient opens exactly what you are looking at. Inputs above roughly 4 KB per side are too large for a URL and the tool tells you so; in that case export the .diff file and send that instead. Do not put sensitive content in a shared link.
Comparisons usually need a normalisation step first. Use the JSON formatter to pretty–print both sides of a JSON comparison, the YAML to JSON converter to compare YAML by structure, the SQL formatter to make two queries comparable, and the base64 encoder and decoder to decode payloads before diffing them. The regex tester helps when you need to strip or normalise a pattern across both inputs, and the hash generator answers the simpler question of whether two files are identical at all — if the hashes match, there is nothing to diff. The full set is in developer tools.
A diff checker compares two blocks of text, code, or files and highlights the differences between them. Named after the Unix diff utility, diff checking is fundamental to software development, content editing, and configuration management. It answers the question: "What changed between version A and version B?"
Diff tools power the core workflows of modern software development. Every Git commit, pull request review, and merge conflict resolution relies on diff algorithms to show what was added, removed, or modified. Beyond code, diff checkers help editors compare document revisions, system administrators audit configuration changes, and analysts verify data transformations.
The most common diff algorithm is the Longest Common Subsequence (LCS), which finds the longest sequence of lines common to both inputs. The differences are then classified:
| Change Type | Symbol | Meaning |
|---|---|---|
| Addition | + (green) | Line exists only in the new version |
| Deletion | - (red) | Line exists only in the old version |
| Modification | ~ (yellow) | Line changed between versions |
| Unchanged | (no mark) | Line is identical in both versions |
Diff display modes:
Advanced features:
git diff --staged to verify exactly what you are committingA diff tool compares two text files and shows differences: additions (green), deletions (red), modifications (yellow/blue). Use cases: code review (compare versions), document editing (track changes), debugging (compare working vs broken), configuration files (verify changes), merge conflicts (identify differences). Alternative to: manual comparison, version control diffs, change tracking in Word. Output formats: side-by-side (columns), inline (unified), split view. This tool provides visual comparison with syntax highlighting and line numbers for easy tracking.
Common algorithms: (1) Myers diff: most common, used by Git, balanced accuracy/performance. (2) Patience diff: better for code, handles rearrangements well. (3) Histogram diff: variant of Patience, faster. (4) Word-level diff: compares words not lines, better for prose. (5) Character-level diff: most granular, shows exact character changes. Myers for general use, Patience for code with moved blocks, word-level for documents, character-level for detailed analysis. Trade-offs: accuracy vs speed. This tool uses optimized Myers algorithm with word-level highlighting for precise comparison.
Whitespace options: (1) Ignore all whitespace: treats spaces, tabs, newlines as identical. (2) Ignore leading/trailing whitespace: only ignore at line edges. (3) Ignore whitespace changes: treats multiple spaces as one. (4) Case-insensitive: treats uppercase/lowercase as same. Use cases: comparing code after reformatting, ignoring indentation changes, comparing across different editors, focusing on content not style. Command-line: diff -w (ignore whitespace), diff -i (case-insensitive). This tool offers toggle options for each whitespace handling mode. Useful for finding actual content changes.
Split (side-by-side): shows both files in parallel columns, left = original, right = modified, visual alignment, easier to read. Best for: small files, quick visual comparison, presentations. Unified (inline): single column with +/- markers, + for additions, - for deletions, context lines unmarked, more compact. Best for: large files, patches, email, version control. Context diff: shows surrounding lines for context. Patch format: unified diff that can be applied with patch command. This tool defaults to split view for clarity, offers unified export for version control integration.
Code review workflow: (1) Compare your branch vs main branch code. (2) Review additions (new functionality), deletions (removed code), modifications (bug fixes). (3) Check for: breaking changes, code quality, test coverage, documentation updates. (4) Leave comments on specific lines. (5) Request changes or approve. Share diffs: export as text or HTML, create patch file for applying changes, share link (if tool supports), screenshot for discussions. Integration: most version control (Git, SVN) has built-in diff, GitHub/GitLab show diffs in pull requests. This tool complements version control for ad-hoc comparisons.
Plain text diff works but not ideal for structured data. Better approaches: (1) JSON diff: special tools compare structure, ignore formatting, highlight value changes, handle nested objects. (2) XML diff: compare DOM structure, ignore attribute order, namespace-aware. (3) Semantic diff: understand language syntax, ignore comments/whitespace. Tools: jq for JSON, xmldiff for XML, language-specific parsers. Formatting first: pretty-print JSON/XML before comparing for better alignment. This tool handles text-based comparison; for complex JSON/XML, use specialized tools or format consistently first.
Patch file: unified diff format that can apply changes to original file. Create patch: diff -u original.txt modified.txt > changes.patch. Apply patch: patch original.txt < changes.patch. Patch format: --- original.txt, +++ modified.txt, @@ -1,4 +1,4 @@ (hunk header), - old lines, + new lines. Reverse patch: patch -R to undo changes. Dry run: patch --dry-run to test without applying. Multiple files: diff -ruN old_dir/ new_dir/ > changes.patch. Git: git diff > changes.patch, git apply changes.patch. This tool can export unified diff format for creating patches.
Large files: use command-line tools (diff, git diff) for better performance, browsers may freeze on files >10MB, consider splitting into chunks, use binary diff tools for non-text files. Directory comparison: diff -r dir1/ dir2/ compares recursively, tools like Meld, Beyond Compare for GUI, identify added/removed files, compare file sizes/timestamps. Optimization: filter files (ignore .git, node_modules), compare hashes first (MD5/SHA256), use incremental comparison, parallel processing for speed. This browser-based tool best for files under 1MB; use desktop tools for larger comparisons.