📋 Table of Contents
You click download for a large application and the file lands almost instantly. Convenient — until you run it. A window opens, a progress bar crawls, and the label underneath reads "Downloading, please wait." Ten minutes later the actual installation finally begins. The file you fetched was never the program. It was a downloader wearing the program's icon.
That is a web installer — also called a stub or online installer — and it is one of three distinct ways software reaches a machine. The stub pulls the real payload from the vendor's servers during setup. A full installer, often labeled offline or standalone, carries the entire program in one file and needs no connection at all. Once something is installed, a third mechanism takes over: the built-in updater, which fetches small delta patches instead of whole new copies.
Which one you want depends on the task. One machine, fast connection: the stub is fine and always current. Archiving a version, imaging a lab, feeding an air-gapped network, or working over a slow link: you want the full installer — and vendors do not always make it easy to find.
1 Why vendors hand you a downloader
A web installer is a bootstrapper. It contains setup logic and a pointer to the vendor's distribution servers, not the application itself. Run it and it checks the current release, picks the build that fits your system — architecture, language, sometimes edition — and downloads exactly that.
The design solves several vendor problems at once. Every user lands on the latest version, so stale copies stop circulating for years on forums. One small file serves every language and architecture. Install completions can be measured, and the heavy payload comes from a content delivery network. Google ships Chrome this way by default, Mozilla's primary Firefox download for Windows has long been a stub, and Microsoft has published runtimes under the explicit name "web installer" for years. For a vendor it is close to ideal. For anyone managing more than one machine, it is a nuisance.
2 What the full installer is actually for
A full installer is self-contained: everything the application needs travels inside the package, and setup runs to completion on a machine that has never seen the internet. That one property carries a lot.
It means you can archive a specific version and reinstall it years later — useful when a new release breaks a workflow and you need to roll back, or when a process requires a known, fixed build. It means downloading once and installing on twenty machines, which matters on slow or metered links. And it is the only format that works for machines with no network path at all — the raw material for air-gapped deployment.
Full installers also suit verification. A fixed file can be published with a checksum or signature, and you can verify the download before it goes anywhere sensitive. A stub can be hashed too, but the payload it fetches is chosen at run time — most of the actual bits sit outside anything you verified.
3 Updates: the third way software arrives
Most of the software on a working machine arrived neither way. It arrived as an update.
Background updaters — Chrome's update service, Firefox's built-in updater, Windows Update, the macOS App Store, a Linux package manager — assume the application is already present. Many ship delta patches: only the portions that changed between two versions, applied to what is already on disk. That is why an update to a large application can finish quickly while a fresh download of the same release takes far longer.
An updater needs two things a full installer does not: an existing installation at a version it recognizes, and a network path to the vendor. On an isolated network there is neither, so updates cross the gap as full packages like everything else. Managed environments often disable automatic updates outright, so versions change when the administrator decides rather than when the vendor does; most major vendors document policy settings for it.
4 Telling them apart before you run anything
Size is the loudest clue, and you do not need exact figures to read it. A browser, an office suite, or a video editor is a large piece of software. If its "installer" arrives in a second or two on an ordinary connection, the file cannot contain the program — it is a stub. The full installer for the same application is a substantial download that takes visible time.
Naming is the second clue. Vendors offering both usually mark them with "web," "online," or "stub" on one side and "offline," "standalone," or "full" on the other. Microsoft's runtime downloads have historically carried the distinction in the product name itself.
Behavior settles any doubt. Disconnect a test machine from the network and run the file: a full installer proceeds normally, while a stub stops almost immediately with a connection error. The reverse test works too — an installer whose progress bar lingers on a step called "downloading" has already told you what it is.
5 Finding the full installer when the vendor buries it
Vendors rarely refuse to publish full installers; they just keep them away from the big button. The stub gets the front page. The complete package sits on an enterprise page, a release archive, or an "other download options" page a few clicks deeper.
The patterns repeat across vendors. Business and enterprise download pages nearly always carry full packages, because IT departments demand them — Chrome's enterprise MSI is the standard example. Release archives are another reliable source: Mozilla publishes complete Firefox installers for every release, language, and architecture on its public archive at ftp.mozilla.org. Pages titled "all platforms and languages" tend to lead to full builds as well.
Because the location differs for every vendor, this site keeps a tracking page: offline installer availability lists which vendors publish full installers and where. When a vendor truly offers none, resist grabbing a repackaged copy from a download portal — a stub from the vendor beats a full installer from a stranger. The guide to safe download sources covers judging sites when you must look beyond the vendor.
Frequently Asked Questions
Is a web installer less trustworthy than an offline installer?
Not inherently — the stub and the payload it fetches both travel over the vendor's own channels. The practical difference is verification and control: a full installer is a fixed file you can check against a published checksum, while a stub's payload is chosen at run time. Stubs can also fail behind restrictive proxies or firewalls that block the download step, which is a reliability problem more than a security one.
Will a full installer I archived still work later?
Yes. It installs the version it contains, regardless of what the vendor has shipped since. Expect the application's own updater to try to bring it current on first launch unless you disable that through the vendor's policy options. Store a checksum alongside the archived file so you can confirm it has not been corrupted before you rely on it.
Why is an update so much smaller than the installer for the same program?
Many updaters ship deltas: only the parts that changed between the installed version and the new one, applied to files already on disk. The download stays small even when the application is large. The trade-off is that a delta is useless without the matching starting version, which is why a damaged installation usually calls for a full installer rather than another update.
Conclusion
The three delivery paths are tools for different jobs. Let the stub handle the quick one-off install on a connected machine. Reach for the full installer whenever a version is worth keeping, a link is slow, or a machine is offline. Updaters are maintenance, not distribution: they keep software current, but only an installer can put it there in the first place.
