Why local file tools beat cloud SaaS

The honest answer is that you cannot know, and for the files that matter, "trust us" is not good enough. The most revealing thing people do is draw a hard line: they will happily use a cloud tool to merge two harmless PDFs, then categorically refuse to put a bank statement, a signed contract, a medical record, or a photo of an ID through the same service. That split is rational. The risk on an ordinary file is nothing; the risk on a sensitive one is a permanent loss of control over a document you can never un-share.

It helps to see why free web tools behave the way they do. The conversion is the bait; the monetization is the trap. The watermark exists to sell its own removal. The email gate exists to harvest your attention. The trial that springs after upload exists because once the file is on their server and the result is on your screen, your leverage is gone and theirs is maximized. The mechanics differ — watermark, signup wall, sneaky trial — but the shape is identical: get the file first, extract value second.

There is also quiet leakage most people never think about. Photos carry GPS coordinates in their EXIF data. PDFs carry author names, editing software, and revision history. Uploading a file for a two-second operation hands all of that over too.

A local tool has none of this leverage because the file never leaves the machine. There is nothing to watermark, nothing to gate, and nothing sitting in someone else's storage afterward. The privacy guarantee stops being a paragraph you have to trust and becomes a property of how the tool is built.

You did nothing wrong. The conversion engine hit a mismatch it did not know how to handle and, instead of telling you, produced broken output silently. Format failures are rarely about the algorithm; they are about what is hidden inside the source file.

The most common invisible failure is encoding. A text file labeled UTF-8 that actually contains ISO-8859-1 or Latin-1 bytes turns into a wall of garbled characters in any conversion. Metadata is next: an EXIF orientation tag that contradicts the actual pixels rotates your image the wrong way; a DOCX that references fonts it never embedded renders its headers in Wingdings; a TIFF-to-PNG conversion produces a blank white square. Then there are legacy ghosts — WMF and EMF metafiles, old Microsoft Works (.wps) documents, Lotus 1-2-3 and Quattro Pro spreadsheets from two decades of corporate archives.

The other class of breakage is fidelity that gets silently dropped. Reshaping a PDF's layout strips the hyperlinks inside it; a slide deck exported to "two per page" quietly loses the links that made it a usable report. You do not notice until someone else clicks a dead link.

The fix is almost always to normalize the source before converting: detect and correct the real encoding, strip the conflicting metadata, and re-save a malformed document cleanly. A cloud converter cannot do this because you cannot inject steps between upload and output — but a local tool lets you chain preprocessing and conversion in one place, and surface a specific diagnostic instead of a generic "conversion failed."

This is one of the most time-sensitive file chores there is, and it is exactly where heavyweight SaaS feels absurd. A real r/pdf post asks for urgent help compressing a 300KB PDF below 150KB — a hard number, set by an upload form, an email attachment cap, or a portal that rejects anything larger. Another common version: shrink a portfolio PDF to fit a limit without damaging its colors.

Online compressors are built for the transaction, not the target. You upload, wait through a queue, download, and discover the free tier either overshot (the file is still too big) or destroyed the quality to get under the limit. You cannot see the resulting size until it is done, and you cannot iterate without re-uploading a confidential file over and over.

Local compression flips that into a loop you control. Try a setting, read the exact output size and inspect the quality, undo it if it went too far, and try the next value — all against the original, which stays untouched next to the result. When the same limit has to hit a whole folder of files, you set the target once and apply it deterministically so file 200 lands under the cap just like file 1. The point is not a dashboard of features; it is hitting a precise number, visibly, on your own machine.

Because the pricing model does not match the work. You do not edit PDFs every day; you edit them in bursts, when a form or a contract or an application demands it. A recurring fee for bursty work feels wrong because it is wrong — the cost is constant and the use is not. Subscriptions fit software you live in. They fit poorly around a shelf of utilities you reach for occasionally and exactly.

The friction is worse than the price. A huge share of "I need a PDF editor" is really "I need to fix one line on one page, today." A signup wall plus a trial timer is a wildly disproportionate tax on a two-minute task. And the gating shows up even inside paid tools: basic things like read-aloud get locked behind a higher tier, so the one feature you need for this specific job is the one you do not have.

This is why people keep building their own tools rather than renting one. One person wrote a free PDF editor precisely because account-gated one-off edits were so painful; others replace an expensive Acrobat license they only touch a few times a month. The logic is consistent: for episodic file work, "owned once, offline, mine" beats "rented, hosted, theirs." The right question is not whether some giant suite could do the job somewhere in its menus — it is whether you can finish a two-minute task without enrolling in anything.

Sometimes the file itself is the problem, and a single-button upload box has no idea what to do with it. These are the jobs that send people searching at midnight, and they share a shape: a specific defect that needs an exact fix, not a generic "convert A to B."

A few real ones. A 70MB generated poster PDF that Firefox, Okular, and Ghostscript all choke on — the fix is not "compress it," it is to re-save or rebuild the file's internals so a normal viewer can cope. A recording of an online stream where every frame is duplicated, which needs a clean drop from 50fps to 25fps by removing the duplicates, not re-encoding every frame and softening the whole video. A DVD-style multi-disk ISO where the converter extracts only the first disk and strands the rest. Pulling one needed file out of a huge Mac disk image. Reframing a vertical clip to widescreen without ugly bars.

The common thread is precision. What decides whether the output is right or merely close is control over the parameters — the frame-handling mode, the page range, the exact target — and a generic web converter hides every one of those behind a single button. A desktop tool can expose them, run the operation entirely offline, and let you inspect the result before committing. That matters twice over here, because these edge-case files are almost always the sensitive ones you would not upload anyway.

The real cost of file work is usually the switching cost. One site for PDFs, another for images, a desktop app for video, a command-line snippet for archives, and a forum thread for recovery advice. Every switch is another chance to upload the wrong file, lose the output, forget which copy is current, or re-learn which converter watermarked your file or damaged its text last time. When every job moves through a different service, the workflow tax becomes larger than the file work itself.

You can see builders responding to exactly this. One person packaged 31+ separate utilities — PDFs, QR codes, image conversion, text tools — into a single app because installing separate tools for each chore was maddening. Another shipped Substage, which attaches one-step commands right to Finder (jpg, 1080p mp4, zip, blur image, optimize PDF, extract PDF page, ffmpeg transcode) so common actions do not require remembering command-line flags. Others want the all-in-one to reach down to the download manager itself.

Breadth here is not bloat. A single job routinely needs more than one operation — inspect a PDF, extract pages, convert the images, rename the outputs, keep the original untouched — and at every seam a single-purpose tool hands you off to another. Keeping adjacent operations in one place, under one trust model, is the difference between finishing a job and assembling it from four. Breadth does not mean a wall of buttons; it means the next step is already where you are.

Renaming one export is trivial. Renaming two hundred digital-art exports with a predictable, ordered pattern before they go to a client — without a single misnumber — is a real job that a drag-one-file-at-a-time web form simply cannot touch. One person needed a safe way to repair over a million filenames that break as they move across NAS, Mac, and Windows. The moment a job has more than a handful of files, one-at-a-time stops being a tool and becomes a chore.

What batch work actually needs is not just speed — it is reviewability. A good batch flow makes it obvious which files were accepted, which were skipped, where the outputs will land, and whether the originals are preserved. It should reduce the anxiety of acting on a folder full of irreplaceable material, not add to it. Two properties matter most. First, determinism: the same inputs and settings produce the same result every time, so you can trust it on file 200, not just file 1. Second, a preview before commit, so you can see the new names or formats before anything is written to disk.

This is precisely the class of work cloud tools handle worst, because their model is one upload, one download. Batch belongs where the files already live.

PDFs are quietly becoming knowledge containers, not just final documents. People want to search across the regions of papers, reports, manuals, and textbooks they already have — and because those documents are often private or large, they want it done locally. A researcher searching a library of annotated papers, a team hunting a clause across manuals, or a student searching highlighted textbook pages all hit the same wall: uploading the whole corpus to a cloud service for a small operation is disproportionate, and often not allowed.

The concrete demand backs this up. One builder wrote client-side Hindi and English OCR because mainstream OCR mangles Unicode and upload-based processing carries privacy and server-cost problems. Another shipped a browser-only PDF accessibility checker. People losing track of screenshots want to find the text inside an image sitting on disk, because a screenshot is a file too, not a note. Each of these is the same interruption: a private file is blocking a real task, and the shortest trustworthy path from input to acceptable output should not route through a stranger's server.

The enabling step is usually OCR — turning a scanned page or a screenshot into searchable, extractable text — done on the machine where the file already lives, with the extraction tied back to the source page so you can verify it.

"Runs in your browser, nothing is uploaded" has become a marketing line, and wanting proof instead of a promise is the right instinct. For a browser tool you can get that proof in about thirty seconds. Open your browser's developer tools, switch to the Network tab, clear it, then run the operation on a throwaway file and watch. A genuinely local tool does its work with no request carrying your file's bytes — the page loads and then goes quiet. If instead a large upload request fires the moment you hit convert, the file is going to a server no matter what the headline said. This is the exact test one r/pdf user walks people through, and it turns "trust us" into something you verify yourself.

Two honest caveats. First, a browser tool can be local today and quietly change in its next update, so the check is per-version, not forever. Second, it only works for tools that claim to process in the browser — a true cloud converter has to upload, and once your file is on its server there is nothing left to inspect, which is exactly why a sensitive document should never go through one in the first place.

A native desktop app lets you verify once and be done. Point a network monitor at it — Little Snitch on macOS, or your firewall's connection log — and you can see whether the app opens any outbound connection at all. The strongest test needs no tools: pull the network cable or turn off Wi-Fi and see if the tool still works. If every operation still runs offline, the privacy claim stops being a policy you are trusting and becomes a fact you just observed.

If the file in question is a PDF specifically, the PDF-focused walkthrough covers the same check plus desktop alternatives.

That exact phrase has quietly become a shared spec. It shows up the same way across r/software, r/windows, and r/android — people now expect a right-click or drag-in converter for images, video, audio, and archives, not just PDFs, and they treat 'upload it to a website to convert' as the fallback you reach for when nothing local exists. The default flipped.

It flipped because the technical excuse for uploading mostly evaporated. The processing that used to justify a server — transcoding a video, running OCR, compressing a batch — now runs fine on the machine already in front of you, thanks to cheap local compute and browser/WASM engines. What the cloud still reliably adds is a queue, a size cap, and a retention policy, which is to say the parts you didn't want.

Two honest caveats keep the expectation realistic instead of a slogan. 'Runs locally' is a spectrum: a browser-tab tool is still bounded by that tab's memory, so it chokes on the 2GB file, while a real desktop app has no such cap and uses your full CPU. And mobile is a genuinely separate story — an Android image-to-PDF utility and a desktop file suite are different products with different limits. On the desktop, though, 'no account, no upload, no size limit' is not wishful thinking for most jobs; it's just the tool being honest about where the work happens.

The failure mode is always discovered too late: an account flagged, a payment lapsed, a password reset that "disconnects" the desktop client — and years of family photos or work files turn out to live only on someone else's computer. The trap is built into the space-saving modes. Dropbox's online-only files and Google Drive's Stream mode don't store your files on your disk; they store pointers that look like files. They open instantly while you're signed in, which is exactly what makes the dependency invisible.

The distinctions worth knowing: Mirror-style sync keeps real bytes on your disk (and only for the files you actually store — a 5 TB plan doesn't need a 5 TB drive if you're using 1 TB). Stream-style sync keeps almost nothing locally unless you mark folders "available offline" — and even those cached copies belong to the sync client, which is entitled to evict them when the account disconnects. A synced folder is also not a backup in the other direction: sync propagates deletions and mistakes just as faithfully as creations.

The principle that fixes all of this: the cloud is a distribution layer, not the system of record. Somewhere there should be one complete copy of everything that matters, on storage that works with no account signed in at all, plus an offline backup of that copy. And an export you haven't verified is a hope, not a copy — check counts and sizes against the source, and spot-check that files actually open, before you trust it.

The bill creeps up because storage sprawl is invisible by design. You never sat down and decided to keep five copies of the same photo library across four services — it happened one "I'll just sync this folder" at a time. A phone auto-backs-up to iCloud, a laptop mirrors the same shots to Google Photos, a project folder lives in both Dropbox and OneDrive because two collaborators used different tools. Each service quietly nudges you past its free tier, and none of them will ever tell you that the file you're paying to store is a duplicate of one you're also paying to store somewhere else.

The trap is that you can't fix what you can't see, and every service shows you only its own slice. The way out is to stop reasoning about it per-cloud and look at the actual bytes in one place. Pull the libraries down to a single drive, then measure: which folders are actually eating the space, which files are exact or near-duplicate copies of each other, and which directories are empty shells left behind by half-finished syncs. Almost always the picture is lopsided — a small number of large files and a surprising pile of duplicates account for most of the cost.

Once you can see it, the decisions get easy. Delete the duplicates, archive the large files you rarely touch to a cheap cold drive, and keep only the genuinely-shared, genuinely-current set in a cloud you actually chose. The goal isn't to abandon the cloud — it's to pay for storage on purpose instead of by accident.

No, and the assumption that it must is mostly a business-model artefact. Spell and grammar checking, format conversion, table extraction, Markdown and PDF export, diffing two drafts — none of it needs a server. Even local language models now handle rewriting and summarising on a laptop, which removes the last technical excuse.

What matters is knowing which of your operations are deterministic and which are judgment calls:

• Deterministic transforms — case changes, encoding fixes, whitespace normalisation, format conversion, checksums — should be exactly reproducible. Same input, same output, every time, no model involved.
• Model-assisted edits — tone changes, rewrites, summaries — are suggestions. They need a visible before-and-after so you're approving a change rather than discovering it later.

Then the practical rules:

• Always diff. The single most valuable habit in a document pipeline: see precisely what changed before accepting it. Rewrites silently drop qualifiers and change meaning.
• Keep the original. Every transform writes a new file; the source stays put.
• Batch the boring parts. Export forty documents to Markdown and PDF from the same preset rather than doing it once per file.
• Watch the network boundary. A tool that's local except when it isn't is the worst case, because you'll assume the wrong one. If it works with the network off, you know.

The same logic covers quick one-off conversions — CSV to Excel, JSON to CSV — that don't deserve a website visit and an upload.

Cloud sync clients don't just add a folder; they redirect Desktop, Documents, and Pictures at the OS level, so "local" paths now point inside the sync root. Combined with files-on-demand — where a file appears in the listing but the bytes live in the cloud — you can genuinely stop knowing what you have on disk. That's not carelessness; the design hides the distinction.

Do this in order, and don't disable anything until the end:

• Inventory first. List what's redirected and where those folders physically point. You can't reason about the fix until you can see the current state.
• Force everything local before you touch settings. Placeholder files aren't files. "Always keep on this device" must complete for the whole tree — and it can take a long time on a large library.
• Verify by count and by hash. Compare file counts and checksums between the sync folder and your intended local destination. Matching folder names prove nothing.
• Copy, don't move. Keep the sync copy intact until verification passes. This is the step that turns a scary operation into a reversible one.
• Repoint the known folders back to real local paths once you have a verified copy.
• Only then unlink the sync client — unlink rather than uninstall first, so a mistake is recoverable.

The uncomfortable part: until the bytes are verified on your disk, the cloud holds the only copy, and any "cleanup" performed before that point is data loss with extra steps.

Leaving a creative suite feels all-or-nothing because it's sold as all-or-nothing, but most of what a monthly subscription actually does for you day to day isn't authoring — it's conversion, export, resizing, and format wrangling. Those are the parts you can replace without giving up the two or three tools you genuinely author in.

The escape plan is an inventory, not a leap:

• List the actual jobs, not the apps. Write down what you did last month: export deliverables to three sizes, convert masters to a client format, strip or preserve metadata, batch-resize for web. Most of that list is recurring plumbing, not creative work.
• Protect fonts and colour profiles first. The failures that make people crawl back are silent ones — a colour profile dropped on export, a font substituted. Test a round-trip on one real file before you trust a workflow.
• Batch-convert deliverables locally. The repeatable output steps — format conversion, resizing to presets, archival PDF — are exactly what a focused local tool does well, offline, with no per-seat fee.
• Keep authoring where you must. If a task needs true layer editing, keep that one app. Replacing the recurring suite functions is the win; replacing the creative core usually isn't worth it.

Migrate the plumbing and keep the craft. You stop paying a monthly fee for functions that are, underneath, just deterministic file operations.

Two things a file tool should tell you and usually doesn't: what it changed, and what it depended on.

Compression. A target-size PDF compression can hit the number several ways. It can downsample the images, re-encode them harder, or rasterise the whole page. The first two keep your text as text. The third turns a searchable document into a picture of a document — smaller, and permanently worse. Same target, same green checkmark, completely different outcome. The check takes five seconds: open the output and try to select a sentence.

Conversion. Local PDF-to-Word is not one implementation. Some tools do the layout reconstruction themselves; many hand off to an installed Word or LibreOffice and inherit that renderer's quirks. That's why the same file converts differently on two machines, and why the feature silently misbehaves on a machine missing the dependency. "Local" and "self-contained" are different claims.

Then there's the class of operations where it ran and it worked are separate facts: redaction that draws black rectangles without removing the text underneath; password removal that clears the open password but leaves permissions in place; a merge that silently drops form fields or bookmarks; a split that invalidates a signature.

So the guarantees worth demanding, stated per operation rather than per product:

• What is preserved — selectable text, form fields, bookmarks, signatures, metadata.
• What is lost, said out loud rather than discovered later.
• What it needs installed to work at all.
• Whether anything left the machine.

And then verify at the file level instead of trusting the progress bar: select text in the output, search the redacted document for the word you redacted, open the converted file somewhere other than the tool that made it.

A local tool that names its tradeoffs is more trustworthy than a cloud tool that hides them behind an animation.

The complaint isn't really about price — it's that a background job stopped being a background job. A disk scan is a long unattended operation: you start it and go do something else. A modal that halts it until you click turns a 40-minute unattended task into a 40-minute task that requires your presence. That's a functional regression, and it's the reliable tell for this whole category: when monetisation reaches into the runtime behaviour of the operation, the tool has been re-pointed at the vendor's funnel rather than the job.

What to require of a replacement:

• The scan finishes unattended. No prompts mid-run, no "resume" after a dialog.
• Limits stated before work starts. Finding out at the end that results are truncated wastes the entire run.
• It answers the actual question. Largest folders, largest files, duplicates, empty directories — as a sortable list you can act on, not only a treemap you can admire.
• The file list stays local. A full path listing is a remarkably complete map of your work, your clients, and your life. It's not a thing to hand to a service in exchange for a free scan.
• Scanning is not welded to cleanup. A tool that pairs analysis with one-click "optimise" is the one that eventually deletes something you needed. Keep the two apart: the scan produces a list, you decide, and a second deliberate operation removes.

On the subscription itself — for a utility you run four times a year, the shape is wrong, not just the price. You'd be renting continuous access to something you use in bursts. Perpetual, or free with honest limits, matches how the tool is actually used, which is also why this category has such a long history of beloved tools going bad in exactly this way.

Treat a generated document as a build artefact, not a download. The thing that produced it optimised for looking plausible, and the preview you're checking is usually rendered by the same engine that wrote the file — so it agrees with itself. Independent verification means opening the output with something that didn't make it.

The failure modes are specific, and worth checking in this order:

• Spreadsheets: formulas pointing at the wrong range, or a static value sitting where a formula should be. Export the sheet to CSV and read the resulting values — that's what the recipient's tools will compute against, and a wrong total is obvious in a flat file in a way it isn't in a styled grid.
• PDFs: text that is secretly an image (no selectable text means no search, no copy-paste, no accessibility), fonts silently substituted, content overflowing the page box, and page count drifting from what you expect. Extracting the text is the fastest whole-file check there is.
• Links: generated documents routinely contain plausible URLs that were never resolved. Pull every link out and check them. A dead link in a paid deliverable reads worse than no link.
• Metadata: the file carries the producing tool's name, sometimes a workspace or account identifier, and timestamps. Set or strip that deliberately before it goes out under your name.
• Three numbers against the source. Not all of them — three that matter, checked against the system of record. This catches the specific class of error where the generator formatted beautifully and computed wrongly.

None of this is distrust of the generator. It's that nobody downstream will distinguish "the AI got it wrong" from "you sent me the wrong number," and the second is the one attached to your name. Build the check into the delivery step once and it costs a couple of minutes per document forever.

Both camps are arguing from real experience, and the disagreement dissolves once you separate two different costs.

Switching cost pushes toward consolidation. Fifteen apps means fifteen update cycles, fifteen licences, fifteen places a file might be, and a genuine attention tax. It's worst on chained jobs — convert, then rename, then zip — where every handoff is a manual step and another chance to lose the output or process the wrong copy.

Bloat cost pushes the other way. An app that does everything tends to open slower, ask for more permissions, add an account, and eventually add a subscription and a feature you never wanted sitting in the path of the one you did. The minimal-PDF-reader crowd isn't being purist: a reader that opens instantly on an old device and never asks for anything is genuinely better at reading than a suite is.

The useful split is by job shape rather than by philosophy:

• Chained, repeated, multi-file jobs — batch conversion, client delivery, archive preparation — belong together. The value is in the chain, and chains break across app boundaries.
• Instant, single-purpose, high-frequency jobs — read this PDF, glance at that image, grab text off a receipt — are better served by something that starts in a hundred milliseconds and does nothing else.

The property that matters more than the app count is whether each tool leaves your files in a state the next one can use: plain formats, no proprietary library, no account required to get your own output back. Fifteen tools that all read and write ordinary files compose fine. One suite that keeps your work inside itself doesn't, however long its feature list is.

The reputation problem and the black-box problem are the same problem. A cleaner that shows you a number and a Clean button has given you nothing to evaluate, so the only thing left to assess is the brand — which is exactly how this category ends up recommended by inertia and then quietly monetised.

Insist on a tool that answers four questions before it removes anything:

• What, exactly? Full paths and per-item sizes, in a list you can sort and scroll. Not "Junk files: 42 GB."
• Why is it safe? A cache is safe because the application regenerates it. That's a reason, and it differs per item — logs, caches, old installers, and orphaned application-support folders have very different consequences. A tool that can't articulate the reason is guessing on your behalf.
• What is it not touching? Browser profiles, saved credentials, documents, anything in your home directory that isn't a cache. Explicit exclusions are more reassuring than a big headline number.
• How do I undo it? Moving to the Trash rather than unlinking costs nothing and turns a mistake into an inconvenience.

Practically, the biggest wins usually aren't caches at all. Find your largest files and folders first — old disk images, forgotten video exports, duplicate libraries, virtual machines — because one 40 GB item you recognise is worth more than every cache on the machine and carries no risk to delete. Then do application caches, from a list you've actually read. Then stop. The last couple of gigabytes are where cleaners start touching things that matter, and it's a bad trade.

One thing worth knowing before you conclude nothing happened: space reporting lags. Snapshots, local backups, and pending trash can all keep a drive looking full for a while after a clean. Wait before deleting more.

Converting a file to find out what it is inverts the order of operations — you are committing to a lossy, time-consuming action to answer a question that should cost nothing. It happens because preview support is owned by whichever application claims the extension, so the moment a folder is heterogeneous, no single app covers it and the fallback is to normalise everything into a format something can open.

Inspection and transformation are different jobs and want different guarantees:

• Inspection must not modify. Reading a RAW file, listing an archive, or rendering the first page of an EPUB should leave the bytes untouched and produce no output file. Anything that writes has stopped being a preview.
• Speed matters more than fidelity. For deciding "keep or delete", an embedded JPEG thumbnail out of a RAW file in 50 ms beats a colour-accurate render in four seconds. Full quality is for after the decision.
• Metadata is usually the answer. Dimensions, duration, codec, bit depth, sample rate, page count, creation date, camera. Most review questions are answered by properties rather than by pixels, and properties are nearly free to read.
• Archives should be browsable, not extracted. A ZIP or 7z's central directory lists the contents without unpacking. Extracting 4 GB to check whether the folder you wanted is in there is the same mistake as converting to preview.
• Comparison needs to be side by side. "Which of these three near-identical exports is the good one" is unanswerable by opening them in sequence.

The same principle explains why a focused local viewer keeps beating a library-based application for this. A media library wants to import, index, and own your files first; that is a reasonable trade for a collection you live in and completely wrong for a folder you are triaging once. When the job is open, look, decide, the cost of the app deciding to manage your files exceeds the value it adds.

Then convert deliberately, on the subset you chose, once you know what you have.

Reading is the wrong tool because you are doing a set-difference problem by eye, and human attention degrades exactly where the differences are sparse. A diff does this correctly in seconds — the reason it feels unavailable is that the obvious route, pasting a manuscript into an online comparison site, is both unwise with unpublished work and useless at this length.

Most of the effort belongs in preparation, and skipping it is why people conclude diffs "don't work" on prose:

• Normalise line endings first. A file that has been through Windows and macOS will report every single line as changed. This alone accounts for most unusable diff output.
• Normalise invisible characters. Smart quotes, en dashes, non-breaking spaces, and trailing whitespace differ between exports of the same text and produce differences that are not edits.
• Reflow to one sentence or one paragraph per line. A word-wrapped file diffs by display line, so a single inserted word marks the entire rewrapped paragraph as changed. This is the highest-value step and the one most often skipped.
• Then diff at word level, not line level. For prose you want to see which words moved, not which lines are non-identical.

With that done, the output becomes navigable: a change map showing where edits cluster. Group it by chapter using whatever your headings are — a diff that says "17 changes, 14 of them in chapters 3 and 9" turns a week of reading into an afternoon on two chapters.

Two cautions. Sort out which copy is authoritative before merging anything, and keep both originals untouched while you work from copies — the failure mode here is merging into the wrong direction and losing an edit you cannot identify afterwards. And read the changes in context rather than as a list; a diff tells you what differs, not which version is better, and that judgement is still yours.

Because opening a file proves the parser works, and compatibility is about what survives a round trip. The test that matters is: open a document produced elsewhere, change one word, save, and send it back — then look at what else moved. That is the operation your collaborators actually perform, and it is where lightweight editors lose material silently.

DOCX and ODT are not really document formats in the sense of "the text plus some formatting". They are containers for a large, loosely specified set of features, and an editor supporting the common 80% will faithfully preserve what it understands and quietly drop the rest. What tends to go missing:

• Styles as opposed to formatting. If a heading is imported as bold 18pt rather than as Heading 2, the document looks identical and its structure is gone — along with the navigation pane, the table of contents, and any downstream conversion that depends on outline levels.
• Tracked changes and comments. The highest-stakes losses, because collaborators assume they persisted. A round trip that discards a reviewer's comments is worse than a failure to open, which at least announces itself.
• Page geometry. Margins, sections, headers and footers, page breaks, column layouts. Fine on screen, wrong when someone prints or submits it.
• Table structure — merged cells, nested tables, column widths — which tends to survive visually and break structurally.
• Fields and automation. Cross-references, numbering, captions. These degrade to static text, so they look right and stop updating.

How to work with a lightweight editor without getting caught:

Do a round-trip test once, deliberately, with a document that has the features you actually use, and compare before and after. Ten minutes buys you an accurate map of what the tool preserves. Then decide which format is authoritative for each document rather than treating them as interchangeable; if collaborators own the file, write in the format they own, however unpleasant. Keep the untouched original of anything you were sent — a lossy round trip is only unrecoverable if you overwrote the source. And for anything final, send a PDF, so page geometry stops being negotiable.