Open a tab or install the app? Six cases that settle it
· 9 min read
Six sourced cases where desktop software beats browser tools, four where the tab wins, and a 7-line rule that picks for you.
You have a file and a job to do with it. One path is a URL: open a tab, drag the file in, download the result. The other is an install: download a program once, then run it a hundred times. Ask which is better in general and you get slogans. Ask "browser tools vs desktop software" about your specific job and you can get an answer, because the two sides fail in different, checkable ways.
This post takes the second approach: six specific cases where installed desktop software wins, each with the mechanism and a test you can run yourself, plus the short list of jobs where the tab is the right answer. The deliverable is a decision rule: seven if-then lines that tell you which to open. Nothing here claims desktop is dying or winning. Both sides will still be here next year.
One boundary before we start. Privacy, whether a browser tool sends your file to a server, belongs to this site's no-upload privacy guide. That post owns the trust boundary and its limits section concedes the custody cases outright. This post starts where that one ends: desktop wins that have nothing to do with who sees your file.
The decision rule, up front
Everything after this section is the evidence.
- Offline, or first visit on a plane? Use desktop. Test: open the tool with the network off and a cleared profile. Failure means it is not an offline tool.
- Same job three or more times, or ten or more files? Script it on desktop. A heuristic, not a measurement. Adjust it to your patience.
- Would losing the tab mid-run hurt? Big batch, background tab, hours of work: use desktop.
- Needs threads or a GPU (encode, render, inference)? Check
self.crossOriginIsolatedin DevTools on the tool page.falsemeans desktop. - Does the workflow start outside the browser (right-click, hot folder, scanner button)? Use desktop.
- One-off, sensitive, small, online? Use a no-upload browser tool.
- Legal hold, audit trail, e-discovery? Use audited desktop software, full stop.
Rules 1–5 and 7 point at desktop. Only rule 6 points at the tab. That looks lopsided until you notice that rule 6 covers most of what most people do most days: one file, right now, gone tomorrow.
1. Offline: the tool you never opened does not exist
Installed software runs with zero connectivity. A browser tool's offline story has a catch: the offline part must be installed while you are still online.
Browser tools work offline through service workers, which MDN describes as scripts that "essentially act as proxy servers that sit between web applications, the browser, and the network (when available)," built "among other things, to enable the creation of effective offline experiences," with the standard setup being a cache of needed assets prepared on install. Install happens on a visit. A tool you have never opened before a flight does not exist offline. Installed software does.
The checkable test takes thirty seconds. Open a fresh browser profile, or clear site data for the tool, turn the network off, and load the tool's URL. If it loads and processes a file, it works offline. If it shows an error page, you have your answer. Run this test at your desk, not at 35,000 feet.
Metered connections are the softer version of the same win. Every first visit to a browser tool downloads the app itself plus its fonts and libraries; on a capped or per-byte connection that costs real money before your file even loads. A program installed back on unmetered Wi-Fi pays that cost once.
2. Scale: background tabs can be thrown away mid-run
This is the win people discover by losing work. A desktop batch process runs until it finishes or fails loudly. A browser batch job runs in a tab, and tabs are disposable property of the browser.
Chrome documents this directly: under memory pressure it discards tabs, shutting down their renderer processes, and "[i]f you navigate back to a tab that's been discarded, it'll reload when clicked," per the tab-discarding explainer. A multi-hundred-file job in a background tab is exactly what gets discarded. The reload restarts the page, not your job. No vendor publishes a per-tab memory cap, so any gigabyte figure you meet in the wild is invented. The honest test is qualitative: would losing this tab mid-run hurt?
Local storage inside the browser has a parallel ceiling. The Origin Private File System is "subject to browser storage quota restrictions, just like any other origin-partitioned storage mechanism," and "[c]learing storage data for the site deletes the OPFS," per MDN's OPFS page. A browser-local working set is capped by an opaque quota and wiped by the same "clear site data" button people click to fix logins. A desktop scratch disk has no equivalent reaper: disk space is disk space, deleted only when you delete it.
Practical form of the rule: if the batch fits in one sitting, in one tab, while you watch it, the tab is fine. If losing the tab would ruin your afternoon, run it on desktop.
3. Automation: the third time, write it down
Opening a tab is cheap once. The tenth time you open the same tab, paste the same kind of file, click the same buttons, and save with the same settings, the tab is not a tool anymore: it is a ritual. Command-line desktop software turns rituals into text.
Two small exemplars carry this section. To convert every clip in a folder, the desktop answer is one line: for f in *.mov; do ffmpeg -i "$f" -c:v libx264 "${f%.mov}.mp4"; done, built on the streams, transcoding, and filter graphs in the ffmpeg manual. To reshape a JSON export the same way every night, the answer is a saved filter: a jq program "takes an input, and produces an output," and filters pipe into each other, per the jq manual. Save the filter, run it from a schedule, gate a build on it. The browser equivalent is pasting the file in again, every time, forever.
Why the browser cannot close this gap is also documented. Writing results back to your own files from a web page passes through permission prompts: FileSystemHandle.requestPermission({mode: 'readwrite'}) asks the user before changes are saved back, and the surrounding flow carries "a lot of security checks," per MDN's OPFS page. Those checks are correct. A random tab should not silently rewrite your disk. They also mean a script writing 400 files asks nothing of anyone, while the tab clicks Save 400 times.
UNVERIFIED: the ImageMagick command-line docs page returned a redirect page when fetched during research, so the batch example above uses ffmpeg (verified) instead of asserting ImageMagick syntax from memory.
The post's heuristic: a job repeated three or more times, or a batch of ten or more files, belongs in a script. Label it as a heuristic. Your threshold may be five and fifty; the direction is what matters.
4. Compute: threads are gated behind two headers
Video encoding, 3D rendering, and local model inference all want the same thing: every core at once, with threads sharing memory. On desktop that is the default. In a browser tab it is a negotiated privilege, and many tools never negotiate it.
The mechanism is specific. Shared-memory multithreading runs on SharedArrayBuffer, and MDN states the price plainly: "[t]o use shared memory your document must be in a secure context and cross-origin isolated." See the SharedArrayBuffer reference. Isolation itself means serving the page with two headers, Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp, without which "the browser won't guarantee sufficient isolation to safely enable those powerful features," per the Chrome team's explainer. A tool whose owner never set those headers crunches numbers single-threaded. Desktop software uses all cores plus dedicated encoders with no header negotiation.
UNVERIFIED: browser GPU specifics, such as WebGPU behavior and support claims, were not verified against vendor docs for this post. The compute win rests on the shared-memory mechanism above, not on any GPU API claim.
Here is the reader-runnable check. Open the tool's page. Press F12 (Cmd+Option+I on Mac) for DevTools. Click Console. Type self.crossOriginIsolated, press Enter. true means multithreaded code paths are available; false means the tool cannot use shared-memory threads whatever its marketing says. A heavy encode, render, or inference job belongs on desktop.
5. OS integration: workflows that start outside the browser
Some jobs begin before any program opens: right-click a file and pick Convert, drop scans into a folder and collect the results, press a button on a scanner or tablet and have software respond. Desktop owns all of these, because the browser is deliberately not allowed to.
The web's file access runs through permission-gated pickers (the per-save flow from section 3), which means no file associations, no context-menu entries, no background daemons watching folders, and no raw paths to local hardware like scanners, tablets, or color profiles. Each of those is a fine privilege for installed software you chose and a dangerous one for any URL you happen to visit, so browsers withhold them from every site equally. If the workflow starts outside the browser, finish it outside the browser.
UNVERIFIED: folder-watching specifics for macOS Shortcuts, Hazel-style utilities, and similar tools were not verified against vendor docs for this post. Treat them as one generic desktop option, a watcher that runs a script on new files, not as a cited feature set.
Capture hardware ships with desktop drivers and desktop expectations: exact DPI, color profiles, button mappings. A browser tab sees whatever the operating system's generic picker exposes: the lowest common denominator by design.
6. Custody: where this post stops and the privacy post takes over
Legal holds, e-discovery, and centrally audited pipelines belong in audited desktop software. That sentence is not argued here. The sibling post's limits section already concedes exactly these workflows to desktop. Read the full boundary, with the two converter exceptions and the inspection checklist, in the no-upload privacy guide. This post's wins end where that section begins: everything above applies even to files nobody considers sensitive.
When the tab wins
Four cases, kept short: the rest of this site makes them at length.
Zero install, zero admin rights. Open the URL and work. On locked-down machines this is the only path, and the tab asks nothing of IT.
Private one-offs. A sensitive file processed locally with no upload beats both the server-side converter and the program you install and never remove. The trust boundary (what "no upload" promises, how to check it, where it stops) is the whole subject of the no-upload privacy guide. Linked, not summarized.
Cross-device and always updated. The same URL on every machine, no updater, no version drift between laptop and desktop. For one-off jobs freshness is pure win; for repeated ones it cuts both ways (see the FAQ).
Free and unlimited versus metered suites. Leaving a capped suite rather than desktop software in general? Start with the online-tools alternative guide, which documents the caps, ads, and wait-before-download pattern.
Concretely: a single Base64 string to decode opens the Base64 encoder/decoder. A malformed API response to inspect opens the JSON formatter/validator. A PDF to squeeze once before sending opens the PDF compressor. One file, right now, gone tomorrow. That is rule 6, and it is the exception that proves the other six rules.
Worked example: one job, both ways
Take one real job: every evening, a folder of twenty product photos must become web-sized JPEGs at consistent quality. The browser way: open the compressor, add twenty files, set quality, run, download twenty results, rename them into the project: twenty minutes of clicking, repeated tomorrow. The desktop way: one saved ffmpeg line over the folder, run from a shortcut, same output names every night, zero clicks after the first. Same pixels, same quality. The difference is repetition, not the codec. Night one, the tab is faster (no setup). By week two the script has repaid its setup ten times over. That crossover is the post in miniature: rule 6 on night one, rule 2 ever after.
The takeaway card
Offline, big, repeated, heavy, outside-in, or audited: install the app. One-off, small, sensitive, and online: open the tab. When unsure, run the two checks: the cleared-profile offline test and the crossOriginIsolated console line. They take a minute together and they answer from evidence, not loyalty.
Related Tools & Further Reading
- Base64 encoder/decoder — the canonical one-off: decode a string in seconds, no install.
- JSON formatter/validator — paste-and-inspect for the single malformed response; script with jq when it becomes nightly.
- PDF compressor — squeeze one PDF before sending, fully in the tab.
- No-upload privacy guide — the trust boundary this post defers to: what stays local, the two exceptions, and the custody limits.
- Online-tools alternative guide — for readers leaving a capped suite rather than desktop software.
Written by
Vittorio Serra
I treat the browser as the least stable interface on the web, and the formats it exposes changed more in the last decade than in the decade before. It grew by accretion, so a client declaring one is announcing a set of features that were true when the string was written rather than now. The response to that has been a reduction scheme: a major version with a small list of actual differences.
Client hints take the opposite approach, reporting the features that matter rather than a descriptive string, and the difference matters for anything parsing the old format. Bot detection rides on the same field and has the same problem. An honest crawler identifies itself and gets blocked by rules written for the dishonest ones, which is why a crawler that wants to be served has to be documented.
Screen and viewport sizes are more stable but have two definitions. The screen size is the display, and the viewport is the area available to the page, which changes with browser chrome and on a phone it changes as bars hide and show. Code that measures the viewport has to handle it changing after load.
Device pixel ratio is the other one. A screenshot taken at one ratio and compared against a layout built for another produces an image that looks wrong for reasons nobody can name. Every page states which value is being parsed and in which specification, because the answer changed more than once and most references predate the current one.