Paste the original on the left and the changed version on the right, and every line is marked as added, removed or unchanged, numbered against both sides so you can find it in the real file. Switch on "show only changes" when the shared text is long and you only care about what moved. Comparing happens in your browser, which matters when the two versions are contract drafts, config files or anything else you would rather not upload to compare.
Most online text tools send whatever you paste to a server, run the work there, and send a result back. Your words sit in someone else's logs, backups and databases, and you have to trust a privacy policy.
Local-first means the opposite: the whole tool is downloaded to your browser and runs on your own device. Nothing you type is transmitted anywhere: not to us, not to anyone. There is no server that could receive it, which is a stronger guarantee than a promise not to look.
Three consequences worth knowing:
You do not have to take that on trust. Open your browser's developer tools, watch the network panel, and type: nothing appears in it.The network's verify page walks through the same check on every Jamuny tool.
An edited line reads as one removal and one addition
Left: timeout = 30
retries = 3
Right: timeout = 60
retries = 3- 1 timeout = 30 + 1 timeout = 60 2 retries = 3
The comparison works line by line, and a changed line is genuinely the old one gone and a new one in its place. Reading the pair together is how every line-based diff presents an edit, including git, and it is why the two are always adjacent.
The alternative, highlighting the changed characters within a line, reads better for a one-word fix and much worse for a rewritten line, which is why line-level is the standard.
The left number is the line in the original, the right is the line in the changed version. They start together and drift apart as lines are added or removed.
That drift is the useful part: after an insertion near the top, every later line has different numbers on each side, and these columns tell you which number to use when you go looking in the actual file.
Windows CRLF and Unix LF endings are normalised before comparing, so a file that only changed line endings reads as identical rather than as every single line rewritten. Without that, a file that has been through a Windows editor produces a diff that is entirely noise.
Comparison is quadratic in the part that genuinely differs, so it stops at about five thousand differing lines and says so rather than freezing the tab. Identical stretches at the start and end cost almost nothing, so a small change inside a very large file is fine.
If you do hit the limit, it usually means the two texts share less than you expected: a re-exported file with different formatting, or two versions that diverged long ago. Comparing a smaller region is both faster and easier to read than a diff where almost every line is marked.
Because the comparison works line by line: a changed line is genuinely the old one gone and a new one in its place. Reading them as a pair is how every line-based diff, including git, presents an edit.
The left number is the line in the original and the right is the line in the changed version. They drift apart as lines are added or removed, which is exactly what makes them useful for finding the spot in the real file.
No. Windows CRLF and Unix LF endings are normalised before comparing, so a file that only changed line endings reads as identical rather than as every line rewritten.
Comparing is quadratic in the part that actually differs, so it stops at about 5,000 differing lines and says so rather than freezing the tab. Identical stretches at the start and end cost almost nothing, so a small change inside a large file is fine.