What Makes a Web App—and Which Examples Qualify

A web application is software delivered through web technologies that lets a user complete a task: edit a document, approve an invoice, manage inventory or submit an order. Opening in a browser is not enough to earn the label; an informational page can do that too.

That distinction remains useful, but the boundary has become less visible. Modern web apps may work offline or appear beside native software on a device, while familiar desktop products now have browser editions. The practical question for a business is therefore not “Does it look like an app?” but “What work can users complete, under what conditions?”

What makes a web application different from a website

A conventional website primarily publishes content for visitors to read or watch. A web application accepts input, applies business rules, stores or retrieves changing data and returns a result tailored to the user. A company profile is a website; a customer portal where users sign in, change an address and download an invoice is a web application.

This is a spectrum rather than a rigid division. An online store may combine editorial product pages with an application-like basket, account area and checkout. A news site can add subscriber settings and saved articles, while a bank can place public information beside a secure transaction system. One domain may therefore contain both a website and several web-application workflows.

Interactivity alone is not a sufficient test. A menu animation or contact form does not necessarily turn a site into an application. More revealing signs are persistent user state, authenticated accounts, validation, calculations, collaboration, transactions and task-specific results.

Two current examples that pass the task test

Google Docs

Google Docs is a clear web-application example because the browser is a working environment, not merely a document viewer. Users can create, edit, share and collaborate on files, and their actions change persistent content. Google’s current Docs instructions also state that changes are saved automatically online and, after offline access is enabled, can be stored on the device and synchronized with Drive after reconnection.

The example exposes several defining characteristics at once: user-generated data, permissions, continuous saving, collaboration and synchronization. It also demonstrates why “web app” does not mean “online only” in every circumstance. Offline behavior is a product capability with setup requirements, not an automatic property of all browser software.

Microsoft 365 for the web

Microsoft’s browser editions provide a second strong example without implying that web and desktop software are identical. Microsoft’s Office for the web documentation says Word, Excel, PowerPoint and OneNote documents can open in a browser, with viewing and editing available from supported Microsoft 365 environments; it also notes that availability depends on the organization’s plan and configuration.

That qualification matters to buyers. A browser edition may share a brand and file formats with a desktop product while differing in entitlement, administration or available functions. The existence of a web app does not prove feature parity, and a procurement decision should be based on the exact workflow and plan rather than the product name.

Other business workflows that fit the definition

The most useful examples are categories of completed work, not a popularity ranking that quickly becomes stale. Common business web applications include:

Customer relationship management: authorized employees create and update customer records, assign work and generate account-specific views.
Accounting: users issue invoices, categorize transactions and produce reports from stored financial data.
Project management: teams change task status, assign owners, attach files and preserve a shared history.
E-commerce checkout: the system validates a basket, calculates totals, captures delivery details and records an order.
Online banking: authenticated customers inspect account data and initiate tightly controlled transactions.
Booking systems: users search changing availability, select an option and create or modify a reservation.

Each category can also have a native mobile app or installed desktop client. The delivery channel does not change the underlying business purpose. A service may offer several clients connected to the same accounts and back-end records.

A web app is not automatically a progressive web app

A progressive web app, or PWA, is a more specific form of web application designed to acquire selected app-like capabilities. Installation is the most visible example, but it should not be treated as a universal web-app requirement. Many capable browser applications are not offered as installable PWAs.

MDN’s current installability guidance explains that an installable PWA needs a web app manifest and must be served through HTTPS or an approved local development address. It also documents an important limitation: installation behavior varies by browser and platform, so an experience that works in one environment cannot be assumed to work identically everywhere.

Offline operation is another frequently misunderstood feature. A manifest can describe how an installed app appears and launches, but offline workflows require deliberate handling of resources and data. For business software, the harder questions concern which actions remain available without a connection, how conflicting edits are resolved and whether sensitive information is stored locally.

What the framework list cannot tell a buyer

A list mixing interface libraries, server frameworks, runtimes and cross-platform toolkits does not identify the best way to build a web application. Those technologies solve different problems. Architecture should follow the product’s users, transactions, integrations, security obligations and maintenance model.

The browser-facing interface is only one layer. A production system may also need identity management, authorization, application logic, databases, APIs, monitoring and recovery procedures. A visually simple approval screen can sit on top of demanding compliance and integration work; a polished public calculator may need little persistent data.

Businesses evaluating a proposed stack should ask for decisions tied to observable requirements:

Which browsers, devices and input methods must the application support?
Which tasks must remain usable on a slow or interrupted connection?
What data is stored in the browser, on the server and by third parties?
How are access rights, audit history and account recovery handled?
Which functions depend on a particular subscription, extension or administrator setting?
How will releases be tested, monitored and reversed if a defect appears?

These answers are more durable than a fashionable framework ranking. They also reveal whether a web application’s central advantage—access without a traditional desktop installation—actually matches the organization’s constraints.

How to decide whether a web app is the right format

A web application is a strong candidate when people need access across managed devices, when updates should reach users centrally and when sharing through links supports the workflow. It can reduce client deployment work, but it does not remove the need for browser testing, security controls, accessibility work or operational support.

A native application may be preferable when a task depends heavily on device hardware, sustained background activity or platform-specific integration. A simple website remains the more economical choice when visitors mainly need stable information and only light interaction. Some products sensibly combine all three forms.

The decisive test is concrete: identify the user, the task, the data that changes and the conditions in which the task must succeed. Google Docs and Microsoft 365 for the web qualify because users perform persistent document work in the browser. Installability, offline support and a particular framework can improve that experience, but none replaces the underlying definition.

A Browser Tab Is Not the Test: What Makes a Web App—and Which Examples Fit