Edit text in place, sign, redact, reorganize. True content-stream rewrite, not stamp-on-top.
LaunchEdit, sign, redact, and reorganize PDF files in your browser. The Adobe Acrobat alternative that runs on your device — no upload, no subscription.
Pixel-perfect PDF diff with word-level text view, metadata + form-field compare, ruler, and exclusion zones.
LaunchSide-by-side or overlay PDF diff with a document-type selector — Document (contracts, reports), AEC / Blueprint (drawings, schematics), or Image-Scan. Highlights pixel-level differences plus a word-level text diff in a modal.
Open any PCB Gerber bundle in your browser. Gerber X2, Excellon, layer compare, snap-to-pad measure, snapshot URLs.
LaunchOpen RS-274X / X2 Gerber and Excellon files. Inspect layers, measure traces, export to PNG / SVG / DXF.
Compress, merge, split, convert, and manipulate PDF files.
Resize, compress, convert, and transform images.
Format, encode, decode, and validate code and data — safe for production secrets.
Convert, compress, and cut audio and video — MP3, WAV, MP4, WebM, Opus — all in your browser, nothing uploads.
Sourdough baker math, canning processing times — kitchen math you should not memorize.
AES-256 file encryption and self-destructing encrypted notes.
Analyze packet captures and run sysadmin diagnostics in your browser — nothing uploads. PCAP Analyzer ships first.
Chart-overlay technical analysis and precision financial math — your screenshots and numbers never leave your device.
Open CAD, BIM, medical, and enterprise files without paying $300-30K/year for the native software. Gerber Viewer ships first.
A "cloud" PDF tool stops working the moment your Wi-Fi blips. A browser-side tool that uses a service worker keeps running. Here is what makes the difference, how to set it up on Loft, and what genuinely still needs the network.
A cloud PDF tool needs the network because the work happens elsewhere. Lose Wi-Fi mid-task and the tool freezes, the upload stalls, the spinner spins. A browser-side tool that’s cached its code just keeps going — the work happens on your machine and doesn’t care whether the network is up. The mechanism that makes this work is the service worker, and it’s not new. Most modern web apps could ship it; most don’t bother.
(I used Loft’s compress-pdf tool on a flight from SFO to JFK last March — full offline, no Wi-Fi purchased, worked end to end. That’s when I knew the pattern was right.)
A service worker is a small script the browser keeps running in the background, separate from the page. It can intercept network requests, cache responses, and serve cached responses without going to the network. When you visit Loft, the browser registers our service worker on first load. After that, every request the page makes goes through the worker first. If the worker has the requested resource cached, it returns it from disk; if not, it fetches from the network and adds it to the cache for next time.
The pillar at /docs/how-it-works/ walks through this in section 3.
Loft uses four separate cache namespaces:
You don’t have to think about which cache holds what. The practical rule: if you’ve used a tool while online, it’ll work offline. Pinning a tool guarantees this — pinned-tool code is explicitly preserved.
This works in airplanes, on trains in tunnels, at conferences where Wi-Fi is overloaded, and in the office while IT is rebooting the router. The file processing never needed the network in the first place; only the code download did, and that’s already cached.
Even with a service worker, a few things will fail offline:
Everything else — every file operation, every calculator, every viewer — runs on your machine and doesn’t care about the network.
The infrastructure pattern. A cloud PDF tool that processes server-side genuinely cannot work offline — the work happens on their server, and reaching the server requires the network. Adding a service worker would only make the splash screen load offline; the moment you tried to use the tool, the missing upload would break.
Browser-side architecture lets us actually deliver offline because the work was already going to happen on your device. The service worker is the last piece that closes the gap.
No. The file you drop in goes into the tab’s memory; processing happens; result downloads. Closing the tab releases everything. The service worker caches code, not your file content. See Post 5 on tab close behaviour.
Updates land on next reload. If we ship a fix while you’re using the site, the new version takes effect after you refresh — your current session is unaffected.
Indirectly, yes. A tool that genuinely works offline is structurally incapable of secretly uploading your file, because there’s no running network connection. Don’t take “works offline” as proof — the Network-tab verification is still the right check — but it’s a strong supporting signal.
Yes, in DevTools → Application → Service Workers → Unregister. Re-registering happens on next visit if you change your mind.
The pillar at /docs/how-it-works/ covers the service-worker architecture in section 3 and the cache layout in section 8. The changelog tracks the offline-related polish work.
