Diff Checker
Compare text or JSON semantically — word-level highlights, fully in your browser.
Bold tokens mark word-level changes inside paired lines. Removed = red, added = green — also distinguished by −/+ markers, not color alone.
How it works
This is two diff tools sharing one page. Text mode is a classic line diff: both inputs are split into lines, a longest-common-subsequence (LCS) pass finds the lines the two sides share, and everything else is marked added or removed. Where a removed line faces an added one, a second word-level LCS pass highlights exactly which tokens changed inside the line — so a one-word edit in an 80-character line reads as a one-word edit, not a full-line replacement.
JSON mode answers a different question: did the data change, regardless of formatting? Both sides are parsed, then deep-compared path by path. The output is a list — added paths, removed paths, and changed paths with their before and after values — that ignores key order, indentation and whitespace completely. Two configs that serialize differently but mean the same thing produce an empty diff, which is precisely what you want when comparing a deployed config against the one in the repo.
The side-by-side view aligns unchanged lines across two columns and is best for reviewing edits in context; the unified view interleaves removals and additions in a single column, the format code review tools and git diff use, and is better for narrow screens and for copying into a ticket. The toggle preserves your inputs, so switch freely. Line numbers track each side independently, exactly as patch tools number them.
Implementation notes, in the spirit of showing assumptions: the line diff is a standard dynamic-programming LCS, which produces minimal edit scripts for inputs within the 5,000 lines-per-side cap. The word pairing inside changed blocks is positional rather than globally optimal — the same trade-off mainstream diff viewers make. And everything runs locally in your tab: configs, contracts and logs never leave the browser, which you can confirm with an open network panel. For converting between config formats before diffing them, the JSON ↔ YAML ↔ TOML converter pairs naturally with this page.
Frequently asked questions
What is the difference between a text diff and a semantic JSON diff?
A text diff compares lines of characters, so reordering keys or reformatting whitespace shows as changes even when the data is identical. A semantic JSON diff parses both sides into structures and compares values by path — `config.limits.rpm` changed from 600 to 800 — ignoring key order, indentation and trailing commas entirely. Use text mode for prose and code, JSON mode whenever both sides parse as JSON.
Can I ignore whitespace differences?
In JSON mode whitespace is ignored automatically, since the comparison happens on parsed values rather than characters. In text mode the diff is exact by design — trailing spaces and tab-vs-space changes are real changes in most code review contexts and hiding them causes bugs. If whitespace noise dominates, run both sides through a formatter first, then diff the formatted output.
How large an input can this handle?
The line diff uses an LCS algorithm whose memory grows with the product of the line counts, so inputs are capped at 5,000 lines per side — enough for substantial config files and source modules. Within that limit the diff computes in well under a second. Everything stays in browser memory with no upload, so there is no server-side limit; for full repositories, git diff remains the right tool.
Is it safe to paste sensitive configs or logs here?
Both panes are processed entirely in your browser tab — the diff algorithm is local JavaScript, there are no network calls on input, and nothing is stored after you close the page. You can verify in the devtools network tab that typing produces zero requests. That makes this safer than diff sites that round-trip content through a server, though usual care with secrets still applies.
How does word-level highlighting decide what changed within a line?
When a removed line is paired with an added line, the two are tokenized into words and whitespace runs and a second LCS pass finds the longest common token sequence. Tokens outside it get the inline highlight. The pairing is positional — the first removed line in a block pairs with the first added line — which matches how humans read replacement edits and how most diff viewers behave.
Built by FORG — AI cost observability for agentic coding. Free tools, no signup, nothing leaves your browser.
Learn about FORG