Open Gmail, a shared Google Doc or your bank’s login page and you’re already inside a web app. What you see is the front half. The logic and the database sit on a remote server, which processes each request and sends back something the browser can render. Nothing gets installed, and the whole thing starts from a URL.
Most sites aren’t set up to be installed, though. The HTTP Archive’s Web Almanac 2025 found the manifest file that Chromium browsers need before offering installation on only about 9% of crawled sites, while service workers appear on about 19%. Chromium no longer requires a service worker for the install prompt, so the manifest figure is the better gauge of installability.
What Are Web Apps?
Webmail, online document editors and project boards all load in a browser from an address, respond to what you do and pull their data from a server. That covers most of what people mean by the term.
Technically, every web app is a website. The reverse doesn’t hold. A brochure site that only displays fixed pages isn’t a web app, because nothing the visitor does changes what the server sends back.
Delivery through the browser changes how software reaches people. The browser loads the app from its address each time, so there’s nothing to install and the version you get is always the live one. IONOS points out that a security fix applied on the server reaches every user at once, unlike an app-store update. TechTarget lists smartphones, tablets and desktops as supported, since anything with a browser can open the app.
You’ll also see it called a web-based application or browser-based software. Same category.
How a Web App Handles a Request
A request goes from the browser to a web server, then on to an application server and a database, and comes back as a response the browser renders. Here’s the cycle in order.
- The user types a URL or clicks a link, and the browser sends an HTTP or HTTPS request.
- The web server receives the request and routes it to the application server.
- The application server runs the business logic, such as checking a login or calculating a total.
- The application server queries the database or calls an external API for the data it needs.
- The server sends a response, either a full HTML page or a data payload in a format such as JSON.
- The browser renders the response, and JavaScript updates the interface without a new page load where the app is built for it.
The browser and the connection sit outside the developer’s control. That’s why TechTarget ties web app speed to both, and it notes that offline access usually requires a progressive web app.
Front End
The front end is everything that runs in the browser: the layout, the buttons and whatever reacts to a click. HTML gives it structure and content, CSS handles layout, color and responsive behavior, and JavaScript takes over once the page has loaded to deal with interactivity and updates.
Browser differences and screen sizes shape most choices here, which is why teams treat front-end development work as its own discipline.
Back End
The back end does the work the user never sees.
It takes requests in, checks permissions and business rules, and reads or writes data. Server languages, frameworks and API design all fall under server-side development.
The web server accepts connections and serves files, while the application server runs the code that decides what each request returns.
Database and Storage
Lenovo’s glossary notes that most web apps keep their data on cloud-based servers or databases, not on the user’s device.
Accounts and permissions live there. So does whatever users create, like documents or orders, along with the session state that lets the app pick up where they left off.
Server-side storage is why the same account opens the same documents on a phone and a laptop. It’s also why a database outage takes the whole app down.
Technology Stack Behind a Web App
Every web app stack boils down to client code, a server-side framework, a database and somewhere to host it all. Each layer has a handful of dominant choices.
- On the client side it’s HTML, CSS and JavaScript, usually with React, Angular or Vue.js on top.
- Server-side code tends to be Node.js, Django, Ruby on Rails or Laravel.
- PostgreSQL, MySQL and MongoDB hold most of the data.
- Hosting runs on cloud platforms such as AWS or Azure, and AWS Lambda covers serverless back ends, where the provider runs code on demand.
JavaScript is the scripting language browsers run natively, and the HTTP Archive’s Web Almanac 2025 found that 98.1% of pages request at least one JavaScript file.
On top of that base sit JavaScript frameworks that structure the interface. React is the most used front-end option in Stack Overflow’s 2025 Developer Survey, at 44.7% of respondents.
PostgreSQL leads the database ranking in the same survey at 55.6%. The application server queries it in step four of the request cycle.
Team skills and the data model matter most, with expected traffic close behind. A closer look at choosing a tech stack for a web app covers those trade-offs.
Not every project needs the full stack. A static web app, which is HTML and CSS served as fixed files, runs without a framework or a database, and Hostinger notes it has very little to maintain.
Types of Web Apps
Guides can’t agree on how many types of web apps exist, because the categories overlap. Static, dynamic, single page, multi page and progressive come up most, and they sort along separate axes.
| Axis | Options | Question it answers |
|---|---|---|
| Content | Static, dynamic | Does the server build responses from user input? |
| Navigation | Single page, multi page | Does each click load a new HTML document? |
| Capability | Regular, progressive | Can it install and work offline? |
Any one app sits on all three axes at once. A progressive web app can be built as a single page or a multi page app, and a dynamic app can use either navigation model.
Static and Dynamic Web Apps
A static web app serves fixed files, so what the developer coded is exactly what the user sees. Portfolios and digital brochures fit here.
Dynamic ones build responses from user input and stored data, the way dashboards, accounts and order histories do.
Pick static when the content rarely changes. It skips the database and the application server entirely, so there’s almost nothing to maintain.
Single Page and Multi Page Applications
The HTTP Archive’s Web Almanac describes a single page application as one HTML page that JavaScript rewrites on each interaction, with no new page fetched from the server. Gmail moves between inbox, drafts and folders this way.
A multi page application works the other way. Each route is its own HTML document, and navigation usually triggers a full page load.
Analytics is where single page apps tend to trip up. As of October 2026, Google’s GA4 documentation states that if virtual page views are not recorded for screen changes, Google Analytics treats the whole app as one page and the metrics skew.
The documented fix is turning on enhanced measurement for page changes based on browser history events, which works when the app uses the History API.
Progressive Web Apps
The business case for progressive web apps usually points at Twitter. Its Twitter Lite PWA, launched in 2017, delivered a 65% increase in pages per session and a 20% decrease in bounce rate, according to Google’s web.dev case study.
Installability is what makes a web app progressive. What the progressive web app model actually asks for, per MDN’s current guidance, is a web app manifest (a JSON file linked from the HTML, with its format defined by the W3C Web Application Manifest specification) plus HTTPS, or localhost during development.
A service worker is not required for installation, though many progressive web apps use one for offline support. Plenty of older tutorials still list it as mandatory.
Safari 17 on macOS Sonoma and later also lets users add any site to the Dock, with or without a manifest, per MDN.
Web Apps by Use Case
Most everyday web apps fall into a few jobs.
Gmail handles email, and Google Docs and Notion cover writing and shared notes. Trello boards are shared by whole teams. Figma and Canva run full graphic editors inside the browser.
On the business side there’s Salesforce for customer records, plus online banking portals, which TechTarget lists among typical web apps. IONOS also cites Microsoft Office Online, which brings Word and Excel to the browser.
Web Apps vs Websites vs Native Apps
What separates a web app from a website is what it does for the visitor. The gap with native apps is about where the software runs and what it can reach.
| Aspect | Website | Web app | Native app |
|---|---|---|---|
| Purpose | Informs, mostly static | Interactive, action-oriented | Interactive, built for one platform |
| Distribution | Web address | Web address | App store download |
| Device features | Browser APIs only | Browser APIs only | Full hardware access |
| Offline use | Needs a connection | Needs a connection unless built for offline | Often works offline |
| Build effort | One codebase | One codebase | One build per platform |
Web App vs Website
The dividing line is purpose, not technology.
IONOS describes websites as informative and typically static. A web app performs a service instead, and Google Maps and Amazon’s online store both land on that side of the line in IONOS’s classification.
IONOS admits the boundary is narrow in practice. TechTarget adds that many websites contain web apps, so one domain can hold both.
Web App vs Native App
Native apps cost more to build because each platform needs its own version. IONOS and AWS both name the single codebase as the web app’s main cost advantage, and AWS adds a shorter time to market.
Reach splits the other way. Mobile users have to open a browser and find a web app, while a native app gets app store discoverability, according to AWS.
Guides disagree on security. Some call native apps the safer format because they sit closer to device protections such as fingerprint login, while IONOS credits web apps with a reduced risk of security failures.
The two claims describe different layers. Device protections favor native apps, and server-side control over the code favors web apps.
What Security Risks Do Web Apps Face?
Broken access control sits at the top of the OWASP Top 10:2025, with security misconfiguration right behind it. Software supply chain failures take third. OWASP calls the list an awareness document, and Invicti notes that Insecure Design cannot be tested directly.
A few details from the 2025 edition are worth keeping in mind.
- This is the eighth edition, and it covers 248 CWEs.
- Broken Access Control stays at #1. On average, 3.73% of tested applications had one or more of its 40 CWEs.
- Security Misconfiguration moves up from #5 to #2, with 3.00% of tested applications having one or more of its 16 CWEs on average.
- Cryptographic Failures drops two places to #4.
- SSRF is now folded into Broken Access Control.
Those percentages are averages across datasets contributed to OWASP, not the result of a controlled study. OWASP’s category pages also quote 100% for these two categories, but the score tables list that figure as the maximum coverage in any single dataset, so it isn’t a typical rate. The 90% cited for the 2021 edition described applications tested for misconfiguration, not applications affected by it.
Authentication and Session Management
Authentication Failures holds #7 in the 2025 list, and OWASP notes that standardized authentication frameworks appear to be helping. The failures it describes are mostly mundane.
- Credential stuffing with breached username and password lists
- Session identifiers exposed in the URL
- The same session ID getting reused after login
- Sessions that survive logout or idle timeouts
OWASP’s fix is a server-side session manager that issues a new random ID after login and invalidates it on logout and timeouts, plus multi-factor authentication where possible. Apps that issue signed tokens follow the same logic, because authentication built on signed tokens holds up only when the tokens are short-lived and validated for issuer, audience and scope.
HTTPS and Data in Transit
OWASP’s Cryptographic Failures entry says all data in transit should be encrypted at the transport layer, which for web apps means HTTPS.
The floor is TLS 1.2 or later with forward secrecy ciphers. HTTP Strict Transport Security (HSTS) then stops browsers from falling back to plain HTTP.
Skip it and an attacker on an insecure network can downgrade the connection to HTTP and steal the session cookie, then replay it to hijack the user’s session. That’s OWASP’s first attack scenario for the category.
Common Vulnerabilities
Each of the top three risks lives in a different layer of the stack.
| Risk | Layer | Documented failure |
|---|---|---|
| Broken Access Control | Server-side code | Checks kept in the front end, bypassed with one curl request |
| Security Misconfiguration | Servers and cloud settings | Default accounts, visible stack traces, open storage permissions |
| Software Supply Chain Failures | Client and server dependencies | Untracked nested packages |
OWASP’s access control guidance also calls for rate limits that cap how often a client can call an API, so automated attack tools do less damage.
For supply chain failures, OWASP points to the 2025 Shai-Hulud attack, the first self-propagating npm worm, which reached over 500 package versions before npm disrupted it.
Where Web Apps Fall Short
Most of a web app’s limits come from the browser sandbox or the platform, not from the app’s own code. Device access, offline use, performance and platform rules are where they show up, and iOS is the strictest of the lot.
AWS’s comparison table lists native device features as not accessible to web apps, including location, camera, microphone, contacts and biometrics.
The same AWS page says progressive web apps can send notifications through the mobile browser and track location. The line is softer than the table suggests.
An offline-capable web app still needs one online visit, because IONOS notes the data is cached on the device during that first connection.
On performance, AWS rates web apps as slower and less responsive than native apps, and adds that features can render differently from browser to browser.
MDN describes WebAssembly as bringing near-native performance to the web from languages such as C, C++ and Rust. That narrows the gap for heavy computation but adds no access to device hardware.
iOS is where the rules get specific, and the dates matter.
- Web Push arrived with iOS and iPadOS 16.4, for web apps added to the Home Screen only (WebKit blog, February 2023).
- The permission request has to follow a direct user action, such as tapping a subscribe button.
- Apple dropped its plan to remove Home Screen web apps in the EU and kept them in iOS 17.4 (Apple Developer, March 2024).
Guides disagree on this. Some say Apple does not support web push, which the WebKit blog contradicts from iOS 16.4 onward, and others say Home Screen web apps were removed in the EU, which Apple’s March 2024 statement contradicts.
None of these limits matter for a content tool or an internal dashboard. They decide the outcome for products that depend on background work or hardware.
When Does a Web App Make Sense?
A web app makes sense when reach and speed to market matter more than deep device access, and one codebase is enough. AWS reaches the same verdict for early-stage startups shipping a minimum viable product.
A plain web app fits when the product has to open on any device without a download and every feature stays inside browser APIs. One team owning one codebase helps too.
Go progressive when people need to install the app or use it offline, or when push notifications matter, and the target platforms support them. Check the iOS conditions before committing.
Native is the answer when the product needs deep hardware access or lives in app stores. AWS cites mobile banking apps as the example, since fingerprint authorization needs native features.
The same call, framed around native, hybrid and cross-platform builds, is covered separately.
A progressive web app is not an automatic upgrade over a plain web app. AWS calls the technology relatively new, with developer and community support still evolving, and notes that browser dependence can increase battery use.
AWS also describes a sequence. Start with a progressive web app to reach the widest audience and collect sign-ups, then move to native or hybrid apps for paying customers. Ship the web app first, and add native only when a documented requirement forces it.
The same decision seen from the mobile side is worked through in this mobile app versus web app comparison.
Web Apps FAQ
Is a hybrid app the same as a web app?
No. A hybrid app gets installed from an app store and can reach device features, because it’s a native app with a browser embedded inside it, according to AWS.
Web apps run in the browser with no installation.
Is SaaS the same as a web app?
No, they answer different questions. SaaS covers how software is sold, while “web app” covers how it’s delivered.
Most SaaS products reach customers as web apps, but a web app can also be a free tool or an internal system with no subscription.
Can a web app be listed in an app store?
Yes on Android, with limits on iOS. Google’s Trusted Web Activity runs a progressive web app inside an Android app that can be published to Google Play, provided the developer owns the site.
Apple’s App Store guideline 4.2 requires an app to go beyond a repackaged website, so an iOS listing needs a native shell with native features.
Can no-code or AI tools build a web app?
Yes, for simple ones. No-code platforms and AI coding assistants can generate a front end, a back end and a database for a basic tool.
Generated code still needs a security review, because OWASP says access control only works in trusted server-side code.
How much does it cost to build a web app?
No single figure applies, because scope sets the price. Features, integrations, authentication, hosting and ongoing maintenance each add cost.
AWS notes that one codebase makes web apps cheaper to build than native apps, which need a separate build for each platform.
Building a First Web App Without Overbuilding
A first web app should ship as a plain browser application and add installation, offline use and push notifications only after real usage justifies them. The order below puts decisions that are costly to reverse first.
- Server-side access checks and HTTPS
- A manifest file for installation
- Offline caching, then push notifications
Security and transport come first because retrofitting them touches every route. Push comes last because the HTTP Archive’s Web Almanac 2025 found 78% of desktop and 48% of mobile notification prompts ignored.
The trade-off is real. Early users get an application that needs a connection and cannot send reminders, which is the price of avoiding unused code.
This order holds as of October 21, 2026. It changes if Safari starts prompting for installation or Apple lifts the Home Screen condition on web push.
- How to Install Pandas in VS Code (pip, venv and Conda) - October 30, 2026
- Top 10 UX and Branding Strategies for SaaS Startups in 2026 - October 30, 2026
- SQLite cheat sheet - October 29, 2026
