%22%2F%3E%3Cg%20fill%3D%22none%22%20stroke%3D%22%23fff%22%20stroke-width%3D%226%22%20stroke-linecap%3D%22round%22%3E%3Cpath%20d%3D%22M14%2020h36%22%2F%3E%3Cpath%20d%3D%22M26%2032h24%22%2F%3E%3Cpath%20d%3D%22M38%2044h12%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
FormatKitFree online diff checker
Diff checker with a patch you can apply
This diff checker costs nothing and asks for no account: paste two versions of a file and it shows the differences in two columns with line numbers on both sides, or as a unified patch in the format diff -u prints. The status bar counts the changed lines and the hunks they fall into, and the patch downloads as a .patch file that git apply accepts without editing. Every box holds 5 MB, and two 5,000-line files with 250 edits between them settle in under two milliseconds.
- 100% free
- No signup
- Side by side or unified
- Exports a .patch file
- Up to 5 MB a side
Paste both versions. The comparison runs as you type; press Ctrl+V on the page to fill the first empty box.
How to check the difference between two files
Paste, pick a view, and leave with a patch.
Load both versions
Paste the original into the left box and the changed version into the right; a Ctrl+V (⌘V on a Mac) that lands on the page rather than in a box goes to the first empty one. Each box accepts 5 MB. CRLF, LF and lone-CR line endings are all understood, and if only one side uses CRLF the status bar says so rather than reporting every line as different.
Choose how much of the file to look at
Context sets how many unchanged lines are kept around each change: 0, 3, 10, or the whole file. The setting drives both views, so the two columns hide the same runs of untouched lines that the patch omits. Tick “Ignore whitespace” when only the indentation moved, and “Ignore case” when the difference is a rename between styles.
Read it side by side, or take the patch
Side by side gives you both sets of line numbers and word-level marks inside every rewritten line. Unified patch gives you the same comparison in the format diff -u prints: --- and +++ headers, @@ hunk ranges and one ± per line. Set the file name in the header, then Copy patch or Download .patch and hand it to git apply.
Technical specifications
| Algorithm | Myers O(ND) with the linear-space middle-snake refinement — the minimal edit script, the same result diff and git diff produce by default |
|---|---|
| Views | Two columns with independent line numbers and word-level marks inside rewritten lines, or a unified patch; the context setting governs both |
| Context | 0, 3, 10 lines or the whole file. Two changes separated by no more than twice the context share a hunk, as GNU diff does |
| Patch format | --- a/name and +++ b/name headers, @@ -l,c +l,c @@ hunk ranges, and \ No newline at end of file where it applies; accepted by git apply and patch -p1 |
| Line endings | CRLF, LF and lone CR all terminate a line; when only one side uses CRLF the page says so instead of reporting every line as changed |
| Size and speed | 5 MB a side. 5,000 lines with 250 changed lines compare in 1.7 ms; 100,000 lines (4.74 MB) with 5% changed take 431 ms |
| Search budget | 60 million wavefront steps. Two files with almost nothing in common exhaust it, and the page then says the diff is valid but no longer the smallest possible |
| Price and processing | Free, no account required, and no daily allowance on how many diffs you take; the comparison and the exported patch are both produced in this browser tab |
Frequently asked questions
What is a diff checker and when do I need one?
A diff checker lines up two versions of the same text and shows what changed between them. It is what you reach for when a config file works on one machine and not on another, when a deployment starts failing and you want to know what moved, or when someone sends back an edited file with no note about what they touched. Everything here runs in the browser, so pasting a production config costs nothing but the paste.
What is a unified patch, and what do the @@ numbers mean?
A unified patch is a plain-text description of a change that other tools can apply, and the @@ line says where in each file the following block sits. In @@ -12,7 +12,9 @@, the first pair means “seven lines of the original starting at line 12” and the second means “nine lines of the new version starting at line 12”; a leading space marks an unchanged line, a minus a removed one and a plus an added one. The count is left out when it is 1 and printed when it is 0, which is why you see @@ -40,0 +41,3 @@ for a pure insertion.
Can I apply the patch this page produces with git?
Yes — the output is a standard unified diff, and git apply accepts it as-is. Download it, put it next to the file, and run git apply changes.patch from the directory the header paths are relative to; the headers are written as a/<name> and b/<name>, which is the -p1 layout git expects by default. GNU patch reads the same file with patch -p1 < changes.patch. Set the file name in the toolbar before you export so the header names the real file rather than the placeholder.
Why is my diff huge after I reformatted the file?
Because a formatter touches almost every line, and four of its habits are invisible on screen: it converts line endings, it re-indents, it strips or adds trailing whitespace, and it may add or remove the newline at the end of the file. Any one of those makes a line differ as far as a byte comparison is concerned. Ticking “Ignore whitespace” collapses runs of spaces and tabs and trims both ends of every line, which usually reduces a thousand-line diff to the dozen lines that really changed. If a large block still looks changed after that, it moved rather than being edited — the code diff page labels moved blocks explicitly.
Side by side or unified — which should I use?
Side by side for reading, unified for sending. Two columns keep both sets of line numbers in view and mark the changed words inside a rewritten line, which is what you want while you are still working out what happened. The unified patch is denser, survives being pasted into a ticket or a chat message without losing its alignment, and is the only one of the two another program can act on.
What does “\ No newline at end of file” mean?
It means the file it follows does not end with a line terminator, and the marker exists because the patch format otherwise could not tell you. Text files conventionally end with a newline; POSIX defines a line as ending in one, and many tools quietly add it on save. When one side has it and the other does not, that alone is a real difference — this page reports it in the status bar as well as marking it in the patch, because it is the kind of change that produces a one-line diff nobody can see.
Are the two files sent to a server?
No. Both sides are compared by JavaScript inside this tab, so the text never crosses the network and there is nothing to delete afterwards — closing the page is enough.
About diffing, and why tools disagree
Almost every comparison you have ever read came out of one paper: Eugene Myers’ An O(ND) Difference Algorithm and Its Variations, published in Algorithmica in 1986. Its insight is that the interesting quantity is not the size of the files but D, the number of edits between them, so a search that walks outwards one edit at a time finds the answer in time proportional to N×D rather than N². Two nearly identical files have a tiny D and compare instantly; two files with nothing in common are the expensive case, which is the opposite of most people’s intuition. This page uses the linear-space refinement from the same paper — a forward and a backward search that meet in the middle, splitting the problem in half at the point they touch — so memory stays proportional to the length of the files rather than to their product.
“Minimal” is a weaker guarantee than it sounds, and it is why two honest tools can show you different diffs of the same pair of files. When several edit scripts are the same length, nothing in the definition says which to prefer, so implementations break the tie by whatever their search happened to reach first. Insert a function into a source file and a minimal script will often pair your new closing brace with the old one, reporting a change that starts in the middle of the previous function — technically optimal, humanly wrong. That is a solvable problem, but not by making the diff smaller: the code diff page anchors on unique lines instead, which trades minimality for a result that reads the way the edit was made.
The unified format is younger than the algorithm and was designed for a different audience: not people, but patch. Larry Wall’s original context diff printed both versions of every changed region in full; the unified variant that GNU diffutils popularised prints each unchanged line once, which halves the size of a patch and is why -U3 became the default everywhere. The three lines of context either side are not decoration — they are how patch re-locates a hunk when the target file has drifted since the patch was written. Set the context to 0 here and you get the tightest possible summary of what changed; set it to 3 and you get something that will still apply next week. If what sits in the two boxes is a pair of JSON payloads rather than a pair of text files, stop using a line diff altogether and match them by key instead.
Where the comparison happens
Neither file leaves the tab. The comparison, the patch and the download are all produced by JavaScript on your own machine, with no request to a server at any point — which is the practical reason a production config or a customer export can be pasted in here at all.