All processing runs in your browser — no files or inputs are uploaded to a server.
Paste the original text on the left and the changed version on the right. Pick a granularity — Line for normal code or prose, Word for paragraph-level prose where you want to see individual word swaps, Character for spotting a typo in a short string or a single-character config drift. Pick a view — Split keeps the two texts side by side with deletions and additions colored independently; Unified renders the standard `+`/`-` style you see in `git diff`.
Reach for this when comparing things that are not in version control: two log lines that seem identical but differ by a hidden character, the JSON response from staging vs. production, a YAML config a colleague sent against the one you have. The diff library (`jsdiff`) runs Myers' algorithm in the browser — nothing is uploaded, so logs containing PII or staging secrets stay on your machine. For comparing files already in a Git repo, `git diff` in the terminal is faster; this tool fills the gap for one-off text-to-text comparison.
Original: port: 8080 host: localhost retries: 3 Changed: port: 8080 host: localhost retries: 5 timeout: 30
port: 8080 host: localhost - retries: 3 + retries: 5 + timeout: 30
Line granularity is the default and matches how most code review happens. The shared lines stay quiet, the changed line shows old / new together, and the new line appears as a pure addition. For YAML or JSON this is usually what you want.
Original: The quick brown fox jumps over the lazy dog. Changed: The quick brown fox jumped over the lazy dog.
The quick brown fox [jumps → jumped] over the lazy dog.
Line granularity would mark the whole sentence as changed. Word granularity highlights only `jumps` → `jumped`, leaving the unchanged words untouched. Useful for proofreading drafts, comparing translations, or spotting why an error message string was tweaked between releases.
Original: api.example.com Changed: api.exаmple.com
api.ex[a → а]mple.com (Cyrillic а, U+0430)
The second `a` is Cyrillic а (U+0430), not Latin a (U+0061) — a classic homograph attack pattern. Line and Word diff would just say "the strings differ" without telling you where. Character granularity isolates the single offending code point so you can see what is actually different.
Both run roughly the same underlying algorithm (Myers diff), but `git diff` works inside a repo with full file history, three-way merges, and rename detection, and emits a patch file you can apply elsewhere. This tool takes two arbitrary text blobs you paste, runs the diff in your browser, and shows it visually. Use `git diff` for anything in version control; use this for one-offs (logs, API responses, two emails) where there is no repo.
Almost always invisible characters. Trailing whitespace, a non-breaking space (U+00A0) instead of a regular space, CRLF vs LF line endings, a zero-width joiner (U+200D) pasted from a chat client. Switch to Character granularity to see exactly which byte differs. For prose, paste both texts into the input and compare in Character mode to confirm.
Not as a built-in toggle in this tool. To ignore trailing whitespace, normalize the inputs first — paste each into a separate temp pane and run `String.prototype.trim()` per line (or pipe through `sed 's/[ \t]*$//'`). Whitespace-sensitive formats like Python or YAML usually want to see whitespace differences; for prose comparison, Word granularity often masks whitespace noise automatically.
Myers diff is O(N × D) where N is total length and D is the size of the edit script — fast when texts are similar, quadratic in the worst case when they differ broadly. Paste two 10K-line files that share 99% of content and the diff finishes instantly; paste two unrelated 10K-line files and the browser may stall for seconds. For very large or very dissimilar inputs prefer a streaming diff CLI like `diff -u` or `delta`.
No — the tool diffs raw text, so two JSON objects with the same keys in different order look different. Pre-format both inputs through the JSON Formatter with a consistent sort, or use `jq --sort-keys` from the CLI before pasting. Structural diff tools (`jd`, `dyff`, `deep-object-diff`) sit at a different layer and understand types rather than just bytes.
Split is easier to scan when changes are localized — eyes track left-to-right and the unchanged context stays anchored. Unified is denser and matches the `git diff` style most developers already read fluently, so it works better when you want to copy the result into a chat or document. For more than a screen of changes, split tends to lose the eye, and unified wins.
Text diff is the problem of finding the shortest edit script that turns one string into another. The dominant algorithm, **Myers diff**, was published in 1986 and is what `git diff`, `jsdiff`, and most modern diff tools run. It frames the problem as a graph search and is O(N × D) — fast when texts are similar, quadratic in pathological cases. **Patience diff** (used by Bazaar and `git diff --patience`) sorts unique lines first to produce more readable output on heavily edited files. **Histogram diff** (Git's default since 2.0) refines Patience for runs of identical lines and is what most developers see day to day.
Granularity changes what counts as a unit. **Line-level** diff treats each line as atomic — works well for code and config because line boundaries match the structure. **Word-level** diff splits on whitespace, ideal for prose where a single-word swap should not redline the whole sentence. **Character-level** diff goes byte by byte, surfacing invisible-character issues (CRLF vs LF, non-breaking spaces, homograph attacks) that line and word diff cannot see.
Three adjacent ideas sit nearby. **Structural diff** (`jd`, `dyff`, `deep-object-diff`) parses the input as JSON / YAML and compares trees, so reordered keys do not register as changes — fundamentally a different operation. **Patch files** (the `+`/`-` text output of `diff -u`) are the canonical exchange format; tools like `patch` apply them to rebuild the changed text. **Three-way merge** (`diff3`, what Git uses to merge branches) compares two versions against a common ancestor to detect conflicts — out of scope for any two-input viewer. This tool sits in the simplest of those slots: take two text blobs, show what changed.
Format and validate JSON. Indented or minified output, with clear error messages.
Encode text to Base64 or decode Base64 back to text. UTF-8 safe.
Percent-encode or decode URL components.
Decode JWT header and payload locally. Signature is not verified — paste tokens at your discretion.
Paste text on both sides to see the diff.
