The deck is due in two hours. The chart you need is on page three of a PDF. The wifi on the flight is down again, the cell signal is gone the way it always is at thirty thousand feet, and the only computer you have is the one in your lap. What can you actually do? The answer turns out to depend almost entirely on which tools you reached for back when you had a connection — specifically, on whether the ones you reached for were honest about needing one.
Most “online PDF” sites will not load on a plane. They are server tools wearing a website costume. The home page comes up looking like a real web page, the layout suggests the tool will work the way other tools work, and then you drop the file and nothing happens because the upload cannot reach anywhere. The tool was always going to run on someone else’s computer. The website was a thin lobby in front of a building you cannot get into without a network.
The five-question checklist
You can mostly tell which tools work on a plane and which do not without leaving your seat at home. The check takes a couple of minutes and saves the entire flight-day category of frustration. Here are the questions to ask, in plain language, before you commit a tool to your “keep this one” list.
Does the home page load with airplane mode on, after at least one earlier visit? If you have visited the page once with internet and then turn airplane mode on, the home page should still load. Browsers keep a copy of recently visited pages on your device, so a page that does not show up when you are offline is one that has decided not to make use of that mechanism. Many sites do not, even when there is no good reason. A site that does not show its home page offline is unlikely to do anything more ambitious than that without a connection.
Does the network panel show a file upload request when you use the tool?Open the developer tools, switch to the Network panel, and use the tool with a small sample file while you have a connection. Watch what fires when you drop the file or click the action button. If a new request appears with a size comparable to the size of your file, that is the upload. The tool needs the network to do the work. On a plane it will fail. If no new request appears, the tool did the work locally; on a plane it will keep working.
Does the page show a “your file is processing on our servers” spinner? The presence of language like “processing on our servers” or “please wait while we convert your file” is a tell, even when the actual upload is hidden. A page that talks about its own servers is a page that has servers in the loop. A page that does the work locally usually says something more like “your file is being converted in your browser,” or it just shows a progress bar without any reference to remote processing.
Does it require you to sign in just to use the basic tool?A sign-in wall in front of a basic file conversion is a strong signal that the tool is server-based and the company wants to associate your usage with an account. It is not a perfect signal — some local-first tools also require accounts for billing reasons — but a free PDF tool that demands an account before it will let you split a document is almost always a server-based product. On a plane, the sign-in itself will fail, and without sign-in the tool will refuse to start.
Does it nudge you to install a desktop app to do something a webpage should be able to do? When a website pushes you toward a desktop installer for a small utility task, ask yourself why. Sometimes the answer is reasonable — the task genuinely benefits from being a real application. Often the answer is that the website version is a sales funnel for a paid desktop product, or that the website is a thin wrapper that needs the desktop app to do the actual work. A real local-first web tool does not need to push an installer at you, because the web tool already runs locally.
A worked example you can do today
Pick a task you actually do. “Convert this PNG to PDF” is a good one because every site claims to do it. Pick three sites that show up at the top of the search results. Visit each one with internet. Use the tool with a small image. Now turn airplane mode on, hard-refresh each page, and try the same task again with the same file.
You will find a pattern. The first site loads its home page from your browser’s cache, displays the drop area, accepts your file, and then does nothing because the upload cannot complete. The second site fails earlier — the home page itself never loads because the page was not designed to render without a fresh connection. The third site, if you picked one that runs locally, completes the conversion exactly as it did before, and the resulting PDF appears in your downloads folder. The third site is the one to keep.
We are not telling you which sites those are because the list changes and your priorities are not ours. We are telling you the test you can run, with airplane mode and a small sample file, in a few minutes, that will sort the survivors from the pretenders. Once you have done it for your handful of regular tasks, you have a working toolkit for the next time the wifi disappears.
Why this matters even when you have a connection
Picking tools that work on a plane is, on its surface, about working without internet. But the same architecture has knock-on effects when the network is fine. Tools that do the work locally do not have an upload speed to fight with, so a 50 megabyte file converts as fast as your laptop can do the math, not as fast as your home connection will tolerate it travelling to a server. There is no per-month upload quota and no login wall, because there is no server costing the operator money on a per-request basis. The same tool that works on a plane works fine on a coffee shop’s unreliable wifi, on a hotel’s captive portal, and on a train ride through a tunnel.
The privacy implications come along for the ride. A tool that does not need to upload your file does not, in fact, upload your file. There is no policy paragraph to read, because there is no upload to write a policy about. You can confirm this with the same Network panel check that tells you whether the tool will work on the plane: if no request fires when you drop the file, then no request fires when you drop the file. The same check answers both questions at once.
These tools used to be more common. The early web had more of them, partly because servers were expensive and operators preferred to push the work out to the user’s machine. Then bandwidth got cheap, the cloud got fashionable, and a generation of product teams built upload-first tools because that was the easy version. The local-first version takes more engineering effort to ship, which is why fewer teams ship it. The good news is that the underlying browser has become much more capable, so the tools that do bother to do the work locally can now handle most of what the upload tools handle.
Why genuinely local tools are rare
Building a tool that works in a browser tab is harder than building one that uploads to a server. The browser is constrained in ways that a server is not. The user’s machine has less memory than your data centre, the user’s connection has less upload bandwidth than the cable between two of your servers, and the user’s attention span runs out at the first hint of a slow page. Engineers who have only ever worked on server tools find the browser frustrating because it does not give them the infinite resources they are used to.
The other reason is incentives. A server-based tool can charge per upload, per page, per conversion, per month. It can lock features behind a sign-in wall and segment users into free and paid tiers based on what their account allows. It can collect telemetry about what kinds of files people are converting, what subjects those files are about, what regions the files come from. A local tool gives the operator none of those levers. The operator gets the satisfaction of building a thing that respects the user’s device, and they get to figure out a different way to pay for the work.
Most teams pick the easy version because their incentive is “ship fast” rather than “the user keeps the file.” That is not a moral failing; it is an incentive structure. The teams that pick the harder version usually do so because the operator personally cares about the difference, often because they got burned by an upload-based tool at some point and decided the world needed at least one alternative. These are the tools you want when the wifi is down and the deck is due.
If you want to use a set of tools that already pass this checklist, every tool on our home page works after the first visit, with airplane mode on, with no upload. Run the test we described on any one of them and you will see the Network panel stay quiet. The reasoning behind why we built it this way, in more depth, is on our about page.