diff --git a/docs/contributing/chat-zulip-org.md b/docs/contributing/chat-zulip-org.md
index 7568eb086b..7a0b08d469 100644
--- a/docs/contributing/chat-zulip-org.md
+++ b/docs/contributing/chat-zulip-org.md
@@ -93,7 +93,7 @@ descriptions for all of them.  Relevant to almost everyone are these:
   folks post with their name as the topic.  Everyone is welcome to
   participate!
 * [#development help](https://chat.zulip.org/#narrow/stream/49-development-help)
-  is for asking for help with any Zulip server/webapp development work
+  is for asking for help with any Zulip server/web app development work
   (use the app streams for help working on one of the apps).
 * [#code review](https://chat.zulip.org/#narrow/stream/91-code-review)
   is for getting feedback on your work.  We encourage all developers
diff --git a/docs/contributing/gsoc-ideas.md b/docs/contributing/gsoc-ideas.md
index 109807ef37..fd2a32d966 100644
--- a/docs/contributing/gsoc-ideas.md
+++ b/docs/contributing/gsoc-ideas.md
@@ -258,10 +258,10 @@ the areas mentioned above are not your main strength.
 
 As a data point, in Summer 2017, we had 4 students working on the
 React Native mobile app (1 focused primarily on visual design), 1 on
-the Electron desktop app, 2 on bots/integrations, 1 on webapp visual
+the Electron desktop app, 2 on bots/integrations, 1 on web app visual
 design, 2 on our development tooling and automated testing
 infrastructure, and the remaining 4 on various other parts of the
-backend and core webapp.
+backend and core web app.
 
 ### Full stack and web frontend focused projects
 
@@ -306,7 +306,7 @@ CSS](https://github.com/zulip/zulip/).
   Expert: Eeshan Garg.
 
 - Optimize performance and scalability, either for the web frontend or
-  the server.  Zulip is already one of the faster webapps out there,
+  the server.  Zulip is already one of the faster web apps out there,
   but there are a bunch of ideas for how to make it substantially
   faster.  This is likely a particularly challenging project to do
   well, since there are a lot of subtle interactions to understand.
@@ -322,8 +322,8 @@ CSS](https://github.com/zulip/zulip/).
 
 [prod-label]: https://github.com/zulip/zulip/issues?q=is%3Aopen+is%3Aissue+label%3A%22area%3A+production%22
 
-- Extract JavaScript logic modules from the Zulip webapp that we'd
-  like to be able to share with the Zulip webapp.  This work can have
+- Extract JavaScript logic modules from the Zulip web app that we'd
+  like to be able to share with the Zulip web app.  This work can have
   big benefits it terms of avoiding code duplication for complex
   logic.  We have prototyped for a few modules by migrating them to
   `static/shared/`; this project will involve closely collaborating
@@ -511,7 +511,7 @@ Zulip React Native mobile app.
   problems that nobody has found yet; in the short term, it needs
   polish, bug finding/squashing, and debugging.  So browse the open
   issues, play with the app, and get involved!  Goals include parity
-  with the webapp (in terms of what you can do), parity with Slack (in
+  with the web app (in terms of what you can do), parity with Slack (in
   terms of the visuals), world-class scrolling and narrowing
   performance, and a great codebase.
 
@@ -556,7 +556,7 @@ Experts: Aman Agrawal, Neil Pilgrim.
 
 - Work on Zulip Terminal, the official terminal client for Zulip.
   zulip-terminal is already a basic usable client, but it needs a lot
-  of work to approach the webapp's quality level.  We would be happy
+  of work to approach the web app's quality level.  We would be happy
   to accept multiple strong students to work on this project.  Our
   goal for this summer is to improve its quality enough that we can
   upgrade it from an alpha to an advertised feature.  **Skills
diff --git a/docs/development/using.md b/docs/development/using.md
index 9fc0ca693a..431c5a30ac 100644
--- a/docs/development/using.md
+++ b/docs/development/using.md
@@ -5,7 +5,7 @@ This page describes the basic edit/refresh workflows for working with
 the Zulip development environment.  Generally, the development
 environment will automatically update as soon as you save changes
 using your editor.  Details for work on the [server](#server),
-[webapp](#web), and [mobile apps](#mobile) are below.
+[web app](#web), and [mobile apps](#mobile) are below.
 
 If you're working on authentication methods or need to use the [Zulip
 REST API][rest-api], which requires an API key, see [authentication in
@@ -80,7 +80,7 @@ the development environment][authentication-dev-server].
     reloaded automatically.
   * For Jinja2 backend templates (`templates/*`), you'll need to reload
     the browser window to see your changes.
-* Any JavaScript exceptions encountered while using the webapp in a
+* Any JavaScript exceptions encountered while using the web app in a
   development environment will be displayed as a large notice, so you
   don't need to watch the JavaScript console for exceptions.
 * Both Chrome and Firefox have great debuggers, inspectors, and
diff --git a/docs/overview/architecture-overview.md b/docs/overview/architecture-overview.md
index 534e9e1296..3a593635f7 100644
--- a/docs/overview/architecture-overview.md
+++ b/docs/overview/architecture-overview.md
@@ -6,7 +6,7 @@ Key codebases
 
 The main Zulip codebase is at <https://github.com/zulip/zulip>.  It
 contains the Zulip backend (written in Python 3.x and Django), the
-webapp (written in JavaScript and TypeScript) and our library of
+web app (written in JavaScript and TypeScript) and our library of
 incoming webhook [integrations](https://zulip.com/integrations)
 with other services and applications (see [the directory structure
 guide](../overview/directory-structure.md)).
@@ -105,7 +105,7 @@ the code is in `zerver/tornado`.
 
 Zulip's HTML is primarily implemented using two types of HTML
 templates: backend templates (powered by the [Jinja2][] template
-engine used for logged-out ("portico") pages and the webapp's base
+engine used for logged-out ("portico") pages and the web app's base
 content) and frontend templates (powered by [Handlebars][]) used for
 live-rendering HTML from JavaScript for things like the main message
 feed.
diff --git a/docs/overview/changelog.md b/docs/overview/changelog.md
index 1cd4755f35..8a1b352876 100644
--- a/docs/overview/changelog.md
+++ b/docs/overview/changelog.md
@@ -90,7 +90,7 @@ log][commit-log] for an up-to-date list of raw changes.
   inline documentation in your
   `/etc/zulip/settings.py`][update-settings-docs].  Notably, we rewrote the
   template to be better organized and more readable in this release.
-- The webapp will now display a warning in the UI if the Zulip server
+- The web app will now display a warning in the UI if the Zulip server
   has not been upgraded in more than 18 months.
   template to be better organized and more readable.
 - The next time users log in to Zulip with their password after
@@ -212,7 +212,7 @@ log][commit-log] for an up-to-date list of raw changes.
 - Upgraded our ancient forked version of bootstrap, on a path towards
   removing the last forked dependencies from the codebase.
 - Upgraded Django to 3.1 (as well as essentially every other dependency).
-- Updated webapp codebase to use many modern ES6 patterns.
+- Updated web app codebase to use many modern ES6 patterns.
 - Upgraded Zulip's core font to Source Sans 3, which supports more languages.
 - Relabeled :smile: and :stuck_out_tongue: emoji to use better codepoints.
 - Reduced the size of Zulip's main JavaScript bundle by removing `moment.js`.
@@ -724,10 +724,10 @@ lose the setting and need to re-enable it.
   verify whether your configuration is working correctly.
 - The Zulip web and desktop apps have been converted to directly count
   all unread messages, replacing an old system that just counted the
-  (recent) messages fully fetched by the webapp.  This one-time
+  (recent) messages fully fetched by the web app.  This one-time
   transition may cause some users to notice old messages that were
   sent months or years ago "just became unread".  What actually
-  happened is the user never read these messages, and the Zulip webapp
+  happened is the user never read these messages, and the Zulip web app
   was not displaying that.  Generally, the fix is for users to simply
   mark those messages as read as usual.
 - Previous versions of Zulip's installer would generate the secrets
@@ -753,7 +753,7 @@ lose the setting and need to re-enable it.
 
 #### Full feature changelog
 - Added sortable columns to all tables in settings pages.
-- Added webapp support for self-service public data exports.
+- Added web app support for self-service public data exports.
 - Added 'e' keyboard shortcut for editing currently selected message.
 - Added support for unstarring all starred messages.
 - Added support for using `|` as an OR operator in sidebar search features.
@@ -771,7 +771,7 @@ lose the setting and need to re-enable it.
   convenient to link to profiles on GitHub, Twitter, and other tools.
 - Added support for choosing which email address to use in GitHub auth.
 - Added a new setting to control whether inactive streams are demoted.
-- Added webapp support for new desktop app features: inline reply
+- Added web app support for new desktop app features: inline reply
   from notifications, and detecting user presence from OS APIs.
 - Added Markdown support for headings, implemented using `# heading`,
   and removed several other unnecessary differences from CommonMark.
@@ -866,7 +866,7 @@ lose the setting and need to re-enable it.
 - Fixed guest users seeing UI widgets they can't use.
 - Fixed several issues with click handlers incorrectly closing compose.
 - Fixed buggy behavior of /me messages not ending with a paragraph.
-- Fixed several major UI issues with the mobile webapp.
+- Fixed several major UI issues with the mobile web app.
 - Fixed HTML styling when copy-pasting content out of Zulip's night theme.
 - Fixed obscure traceback with Virtualenv 16.0.0 unexpectedly installed.
 - Added a new visual tool for testing webhook integrations.
@@ -1166,7 +1166,7 @@ Zulip installations; it has minimal changes for existing servers.
 - Fixed several bugs with progress bars when uploading files.
 - Fixed several bugs in `manage.py register_server`.
 - Fixed several minor real-time sync issues with stream settings.
-- Fixed some tricky corner cases with the webapp's caching model and
+- Fixed some tricky corner cases with the web app's caching model and
   narrowing to the first unread message.
 - Fixed confusing intermediate states of group PMs online indicators.
 - Fixed several subtle unread count corner case bugs.
diff --git a/docs/overview/release-lifecycle.md b/docs/overview/release-lifecycle.md
index 133abd3bce..38aaa0c1a8 100644
--- a/docs/overview/release-lifecycle.md
+++ b/docs/overview/release-lifecycle.md
@@ -18,12 +18,12 @@ security support policies. In short:
   highly recommend subscribing so that you are notified about new
   security releases.
 * Zulip Cloud runs the branch that will become the next major
-  server/webapp release, so it is always "newer" than the latest
+  server/web app release, so it is always "newer" than the latest
   stable release.
 
-## Server and webapp
+## Server and web app
 
-The Zulip server and webapp are developed together in the [Zulip
+The Zulip server and web app are developed together in the [Zulip
 server repository][zulip-server].
 
 ### Stable releases
@@ -44,7 +44,7 @@ server repository][zulip-server].
   upgrading to the latest maintenance release in that series, so that
   you use the latest version of the upgrade code.
 
-Starting with Zulip 4.0, the Zulip webapp displays the current server
+Starting with Zulip 4.0, the Zulip web app displays the current server
 version in the gear menu.  With older releases, the server version is
 available [via the API](https://zulip.com/api/get-server-settings).
 
@@ -126,7 +126,7 @@ See also our [security model][security-model] documentation.
 
 ### Upgrade nag
 
-Starting with Zulip 4.0, the Zulip webapp will display a banner
+Starting with Zulip 4.0, the Zulip web app will display a banner
 warning users of a server running a Zulip release that is more than 18
 months old. We do this for a few reasons:
 
@@ -210,7 +210,7 @@ of our [upgrade nag](#upgrade-nag).
   upgrade all users after a new security release.
 
   New desktop app releases rarely contain new features, because the
-  desktop app tab inherits its features from the Zulip server/webapp.
+  desktop app tab inherits its features from the Zulip server/web app.
   However, it is important to upgrade because they often contain
   important security or OS compatibility fixes from the upstream
   Chromium project.
diff --git a/docs/production/authentication-methods.md b/docs/production/authentication-methods.md
index 3a127e338e..d5bbdcd36e 100644
--- a/docs/production/authentication-methods.md
+++ b/docs/production/authentication-methods.md
@@ -456,7 +456,7 @@ IdP.
 ### IdP-initiated SSO
 
 The above configuration is sufficient for Service Provider initialized
-SSO, i.e. you can visit the Zulip webapp and click "Sign in with
+SSO, i.e. you can visit the Zulip web app and click "Sign in with
 {IdP}" and it'll correctly start the authentication flow.  If you are
 not hosting multiple organizations, with Zulip 3.0+, the above
 configuration is also sufficient for Identity Provider initiated SSO,
diff --git a/docs/subsystems/caching.md b/docs/subsystems/caching.md
index 9a54855974..61c2c8205f 100644
--- a/docs/subsystems/caching.md
+++ b/docs/subsystems/caching.md
@@ -252,7 +252,7 @@ apps; details like which users exist, with metadata like names and
 avatars, similar details for streams, recent message history, etc.
 
 This data is fetched in the `/register` endpoint (or `page_params`
-for the webapp), and kept correct over time.  The key to keeping these
+for the web app), and kept correct over time.  The key to keeping these
 state up to date is Zulip's
 [real-time events system](../subsystems/events-system.md), which
 allows the server to notify clients whenever state that might be
diff --git a/docs/subsystems/dependencies.md b/docs/subsystems/dependencies.md
index fbc3a9c324..39519b0423 100644
--- a/docs/subsystems/dependencies.md
+++ b/docs/subsystems/dependencies.md
@@ -81,7 +81,7 @@ no longer had time for them.
 
 One case where we apply added scrutiny to third-party dependencies is
 JS libraries.  They are a particularly important concern because we
-want to keep the Zulip webapp's JS bundle small, so that Zulip
+want to keep the Zulip web app's JS bundle small, so that Zulip
 continues to load quickly on systems with low network bandwidth.
 We'll look at large JS libraries with much greater scrutiny for
 whether their functionality justifies their size than Python
diff --git a/docs/subsystems/emoji.md b/docs/subsystems/emoji.md
index a0cae95d9c..d0c9bcfa61 100644
--- a/docs/subsystems/emoji.md
+++ b/docs/subsystems/emoji.md
@@ -43,7 +43,7 @@ able to support deprecating old realm emoji in a sensible way.
 We use the [iamcal emoji data package][iamcal] to provide sprite
 sheets and individual images for our emoji, as well as a data set of
 emoji categories, code points, etc.  The sprite sheets are used
-by the Zulip webapp to display emoji in messages, emoji reactions,
+by the Zulip web app to display emoji in messages, emoji reactions,
 etc.  However, we can't use the sprite sheets in some contexts, such
 as missed-message and digest emails, that need to have self-contained
 assets.  For those, we use individual emoji files under
diff --git a/docs/subsystems/events-system.md b/docs/subsystems/events-system.md
index 6f4c1b62f7..c23d705642 100644
--- a/docs/subsystems/events-system.md
+++ b/docs/subsystems/events-system.md
@@ -386,7 +386,7 @@ coverage data.
 
 #### page_params
 
-In the Zulip webapp, the data returned by the `register` API is
+In the Zulip web app, the data returned by the `register` API is
 available via the `page_params` parameter.
 
 ### Messages
diff --git a/docs/subsystems/hashchange-system.md b/docs/subsystems/hashchange-system.md
index f82b029772..a1322b70d7 100644
--- a/docs/subsystems/hashchange-system.md
+++ b/docs/subsystems/hashchange-system.md
@@ -39,7 +39,7 @@ different flows:
   another part of the overlay, which should update the hash but not
   re-trigger loading the overlay (which would result in a confusing
   animation experience).
-* The user is in a part of the webapp, and reloads their browser window.
+* The user is in a part of the web app, and reloads their browser window.
   Ideally the reloaded browser window should return them to their
   original state.
 * A server-initiated browser reload (done after a new version is
diff --git a/docs/subsystems/html-css.md b/docs/subsystems/html-css.md
index 98f20e5f75..ed5bf8769c 100644
--- a/docs/subsystems/html-css.md
+++ b/docs/subsystems/html-css.md
@@ -76,7 +76,7 @@ context is defined and where it can be found.
 ### Backend templates
 
 For text generated in the backend, including logged-out ("portico")
-pages and the webapp's base content, we use the [Jinja2][] template
+pages and the web app's base content, we use the [Jinja2][] template
 engine (files in `templates/zerver`).
 
 The syntax for using conditionals and other common structures can be
diff --git a/docs/subsystems/performance.md b/docs/subsystems/performance.md
index 1a9609ce6b..0fd43d7c7a 100644
--- a/docs/subsystems/performance.md
+++ b/docs/subsystems/performance.md
@@ -9,10 +9,10 @@ First, a few notes on philosophy.
 
 * We consider it an important technical goal for Zulip to be fast,
   because that's an important part of user experience for a real-time
-  collaboration tool like Zulip.  Many UI features in the Zulip webapp
+  collaboration tool like Zulip.  Many UI features in the Zulip web app
   are designed to load instantly, because all the data required for
   them is present in the initial HTTP response, and both the Zulip
-  API and webapp are architected around that strategy.
+  API and web app are architected around that strategy.
 * The Zulip database model and server implementation are carefully
   designed to ensure that every common operation is efficient, with
   automated tests designed to prevent the accidental introductions of
@@ -177,9 +177,9 @@ The request to generate the `page_params` portion of `GET /`
 /api/v1/register](https://zulip.com/api/register-queue) used by
 mobile/terminal apps) is one of Zulip's most complex and expensive.
 
-Zulip is somewhat unusual among webapps in sending essentially all of the
-data required for the entire Zulip webapp in this single request,
-which is part of why the Zulip webapp loads very quickly -- one only
+Zulip is somewhat unusual among web apps in sending essentially all of the
+data required for the entire Zulip web app in this single request,
+which is part of why the Zulip web app loads very quickly -- one only
 needs a single round trip aside from cacheable assets (avatars, images, JS,
 CSS).  Data on other users in the organization, streams, supported
 emoji, custom profile fields, etc., is all included.  The nice thing
@@ -191,7 +191,7 @@ who have a lot of latency to the server.
 There are only a few exceptions where we fetch data in a separate AJAX
 request after page load:
 
-* Message history is managed separately; this is why the Zulip webapp will
+* Message history is managed separately; this is why the Zulip web app will
   first render the entire site except for the middle panel, and then a
   moment later render the middle panel (showing the message history).
 * A few very rarely accessed data sets like [message edit
@@ -219,7 +219,7 @@ We consider any organization having normal `page_params` fetch times
 greater than a second to be a bug, and there is ongoing work to fix that.
 
 It can help when thinking about this to imagine `page_params` as what
-in another webapp would have been 25 or so HTTP GET requests, each
+in another web app would have been 25 or so HTTP GET requests, each
 fetching data of a given type (users, streams, custom emoji, etc.); in
 Zulip, we just do all of those in a single API request.  In the
 future, we will likely move to a design that does much of the database
@@ -234,14 +234,14 @@ of active optimization work.
 
 Bulk requests for message content and metadata ([`GET
 /messages`](https://zulip.com/api/get-messages)) account for ~3% of
-total HTTP requests.  The zulip webapp has a few major reasons it does
+total HTTP requests.  The zulip web app has a few major reasons it does
 a large number of these requests:
 
 * Most of these requests are from users clicking into different views
-  -- to avoid certain subtle bugs, Zulip's webapp currently fetches
+  -- to avoid certain subtle bugs, Zulip's web app currently fetches
   content from the server even when it has the history for the
   relevant stream/topic cached locally.
-* When a browser opens the Zulip webapp, it will eventually fetch and
+* When a browser opens the Zulip web app, it will eventually fetch and
   cache in the browser all messages newer than the oldest unread
   message in a non-muted context.  This can be in total extremely
   expensive for users with 10,000s of unread messages, resulting in a
diff --git a/docs/subsystems/presence.md b/docs/subsystems/presence.md
index ec67ec972b..66a16ec512 100644
--- a/docs/subsystems/presence.md
+++ b/docs/subsystems/presence.md
@@ -13,7 +13,7 @@ scalability problems for a team chat tool like Zulip.
 There's a lot of performance-related details in the backend and
 network protocol design that we won't get into here.  The focus of
 this is what one needs to know to correctly implement a Zulip client's
-presence implementation (e.g. webapp, mobile app, terminal client, or
+presence implementation (e.g. web app, mobile app, terminal client, or
 other tool that's intended to represent whether a user is online and
 using Zulip).
 
@@ -23,11 +23,11 @@ requests contains a few parameters.  The most important is "status",
 which had 2 valid values:
 
 * "active" -- this means the user has interacted with the client
-  recently.  We use this for the "green" state in the webapp.
+  recently.  We use this for the "green" state in the web app.
 * "idle" -- the user has not interacted with the client recently.
   This is important for the case where a user left a Zulip tab open on
   their desktop at work and went home for the weekend.  We use this
-  for the "orange" state in the webapp.
+  for the "orange" state in the web app.
 
 The client receives in the response to that request a data set that,
 for each user, contains their status and timestamp that we last heard
diff --git a/docs/subsystems/widgets.md b/docs/subsystems/widgets.md
index 3dcd452bca..c38d21c7a6 100644
--- a/docs/subsystems/widgets.md
+++ b/docs/subsystems/widgets.md
@@ -92,7 +92,7 @@ invoke, and they may share validation code.)
 ### Availability
 
 The above commands are available for all Zulip servers
-that use 1.9 or above.  You must use the webapp client to
+that use 1.9 or above.  You must use the web app client to
 get the features; other clients will send the messages
 without any translation (e.g. "/day" will just be a message
 that says "/day" if you use the mobile app).
@@ -106,7 +106,7 @@ launch widgets by sending one of the following messages:
 - /poll
 - /todo
 
-The webapp client provides the "widget experience" by
+The web app client provides the "widget experience" by
 default. Other clients just show raw messages like
 "/poll", and should be adding support
 for widgets soon.
@@ -133,11 +133,11 @@ to the database).  This data will also be included
 in the normal Zulip message event payload.  Clients
 can choose to ignore the submessage-related data, in
 which case they'll gracefully degrade to seeing "/poll".
-Of course, the webapp client actually recognizes the
+Of course, the web app client actually recognizes the
 appropriate widgets.
 
-The webapp client will next collect poll options and votes
-from users.  The webapp client has
+The web app client will next collect poll options and votes
+from users.  The web app client has
 code in `submessage.js` that dispatches events
 to `widgetize.js`, which in turns sends events to
 individual widgets.  The widgets know how to render
diff --git a/docs/testing/philosophy.md b/docs/testing/philosophy.md
index e6f89a5d4d..3694545a50 100644
--- a/docs/testing/philosophy.md
+++ b/docs/testing/philosophy.md
@@ -141,7 +141,7 @@ Some examples of this philosophy:
   run, and produce this output".
 
 In the Zulip context:
-* Zulip uses the same API for our webapp as for our mobile clients and
+* Zulip uses the same API for our web app as for our mobile clients and
   third-party API clients, and most of our server tests are written
   against the Zulip API.
 * The tests for Zulip's incoming webhooks work by sending actual
diff --git a/docs/testing/testing-with-puppeteer.md b/docs/testing/testing-with-puppeteer.md
index 8cdaa8d2ab..ac611a9a80 100644
--- a/docs/testing/testing-with-puppeteer.md
+++ b/docs/testing/testing-with-puppeteer.md
@@ -28,7 +28,7 @@ The Puppeteer tests use a real Chromium browser (powered by
 [puppeteer](https://github.com/puppeteer/puppeteer)), connected to a
 real Zulip development server.  These are black-box tests: Steps in a
 Puppeteer test are largely things one might do as a user of the Zulip
-webapp, like "Type this key", "Wait until this HTML element
+web app, like "Type this key", "Wait until this HTML element
 appears/disappears", or "Click on this HTML element".
 
 For example, this function might test the `x` keyboard shortcut to
diff --git a/docs/testing/testing.md b/docs/testing/testing.md
index 5c1da100f5..34531100d9 100644
--- a/docs/testing/testing.md
+++ b/docs/testing/testing.md
@@ -3,7 +3,7 @@
 Zulip takes pride in its extensive, carefully designed test suites.
 For example, `test-backend` runs a complete test suite (~98% test
 coverage; 100% on core code) for the Zulip server in under a minute on
-a fast laptop; very few webapps of similar scope can say something
+a fast laptop; very few web apps of similar scope can say something
 similar.
 
 This page focused on the mechanics of running automated tests in a
diff --git a/docs/translating/translating.md b/docs/translating/translating.md
index b49eb41f3a..4c5d7d317f 100644
--- a/docs/translating/translating.md
+++ b/docs/translating/translating.md
@@ -46,9 +46,9 @@ to any languages that you'd like to contribute to (or add new ones).
    several resource files:
    * `mobile.json` is for the iOS/Android mobile apps.
    * `desktop.json` is for the parts of the Zulip desktop apps that
-     are not shared with the Zulip webapp.
+     are not shared with the Zulip web app.
    * `django.po` and `translations.json` have strings for the next
-     major release of the Zulip server and webapp (which is what we
+     major release of the Zulip server and web app (which is what we
      run on chat.zulip.org and Zulip Cloud).
    * The variants of `django.po` and `translations.json` with names
      starting with a version, like, `4-x--`, are strings for Zulip's
@@ -121,7 +121,7 @@ There are a few ways to see your translations in the Zulip UI:
   can view the login page in German using
   `http://localhost:9991/de/login/`.  This works for any part of the
   Zulip UI, including portico (logged-out) pages.
-* For Zulip's logged-in UI (i.e. the actual webapp), you can [pick the
+* For Zulip's logged-in UI (i.e. the actual web app), you can [pick the
   language](https://zulip.com/help/change-your-language) in the
   Zulip UI.
 * If your system has languages configured in your OS/browser, Zulip's
@@ -193,7 +193,7 @@ capitalization in general.  This means that:
     - Incorrect: "Url"
 
 The Zulip test suite enforces these capitalization guidelines in the
-webapp codebase [in our test
+web app codebase [in our test
 suite](../testing/testing.html#other-test-suites)
 (`./tools/check-capitalization`; `tools/lib/capitalization.py` has
 some exclude lists, e.g. `IGNORED_PHRASES`).
diff --git a/static/js/activity.js b/static/js/activity.js
index d67db4e4f0..32406bf328 100644
--- a/static/js/activity.js
+++ b/static/js/activity.js
@@ -138,7 +138,7 @@ export function compute_active_status() {
     // computer, and IDLE (aka orange circle) if the user might not
     // be:
     //
-    // * For the webapp, we just know whether this window has focus.
+    // * For the web app, we just know whether this window has focus.
     // * For the electron desktop app, we also know whether the
     //   user is active or idle elsewhere on their system.
     //
diff --git a/static/js/echo.js b/static/js/echo.js
index 5c506a9928..9cf0c2ec55 100644
--- a/static/js/echo.js
+++ b/static/js/echo.js
@@ -124,7 +124,7 @@ export function build_display_recipient(message) {
             // where the server might dynamically create users in
             // response to messages being sent to their email address.
             //
-            // TODO: It might be cleaner for the webapp for such
+            // TODO: It might be cleaner for the web app for such
             // dynamic user creation to happen inside a separate API
             // call when the pill is constructed, and then enforcing
             // the requirement that we have an actual user object in
diff --git a/static/js/markdown_config.js b/static/js/markdown_config.js
index efb95d362b..1a801e8300 100644
--- a/static/js/markdown_config.js
+++ b/static/js/markdown_config.js
@@ -6,7 +6,7 @@ import * as user_groups from "./user_groups";
 
 /*
     This config is in a separate file for partly
-    tactical reasons.  We want the webapp to
+    tactical reasons.  We want the web app to
     configure this one way, but we don't want to
     share this code with mobile.
 
diff --git a/static/js/reload.js b/static/js/reload.js
index 1848805cc1..01d969bfeb 100644
--- a/static/js/reload.js
+++ b/static/js/reload.js
@@ -243,7 +243,7 @@ export function initiate({
     reload_state.set_state_to_pending();
 
     // We're now planning to execute a reload of the browser, usually
-    // to get an updated version of the Zulip webapp code.  Because in
+    // to get an updated version of the Zulip web app code.  Because in
     // most cases all browsers will be receiving this notice at the
     // same or similar times, we need to randomize the time that we do
     // this in order to avoid a thundering herd overloading the server.
diff --git a/static/js/util.js b/static/js/util.js
index 253c8658d1..ad43415f83 100644
--- a/static/js/util.js
+++ b/static/js/util.js
@@ -284,12 +284,12 @@ export function clean_user_content_links(html) {
     for (const elt of content.querySelectorAll("a")) {
         // Ensure that all external links have target="_blank"
         // rel="opener noreferrer".  This ensures that external links
-        // never replace the Zulip webapp while also protecting
+        // never replace the Zulip web app while also protecting
         // against reverse tabnapping attacks, without relying on the
         // correctness of how Zulip's Markdown processor generates links.
         //
         // Fragment links, which we intend to only open within the
-        // Zulip webapp using our hashchange system, do not require
+        // Zulip web app using our hashchange system, do not require
         // these attributes.
         const href = elt.getAttribute("href");
         let url;
diff --git a/static/shared/README.md b/static/shared/README.md
index 5625337593..f29950b510 100644
--- a/static/shared/README.md
+++ b/static/shared/README.md
@@ -3,7 +3,7 @@ and are also incorporated by the Zulip mobile app.
 
 Note that the deployment cycles are different:
 
- * In the webapp, this code is deployed in the same way as the rest of
+ * In the web app, this code is deployed in the same way as the rest of
    the web frontend: it's part of the server tree, and the browser
    gets it from the server, so the client is always running the same
    version the server just gave it.
diff --git a/static/shared/js/emoji.js b/static/shared/js/emoji.js
index 98bb7491d3..4477459596 100644
--- a/static/shared/js/emoji.js
+++ b/static/shared/js/emoji.js
@@ -4,7 +4,7 @@ import _ from "lodash";
 let emoji_codes = {};
 
 // `emojis_by_name` is the central data source that is supposed to be
-// used by every widget in the webapp for gathering data for displaying
+// used by every widget in the web app for gathering data for displaying
 // emojis. Emoji picker uses this data to derive data for its own use.
 export const emojis_by_name = new Map();
 
diff --git a/static/styles/app_components.css b/static/styles/app_components.css
index 27cea005c3..d7431e8562 100644
--- a/static/styles/app_components.css
+++ b/static/styles/app_components.css
@@ -1,4 +1,4 @@
-/* Reusable, object-oriented CSS base components for the Zulip webapp
+/* Reusable, object-oriented CSS base components for the Zulip web app
    (not included in the portico CSS) */
 
 .flex {
@@ -515,7 +515,7 @@ div.overlay {
     color: hsl(0, 0%, 100%);
 }
 
-/* Implement the webapp's default-hidden convention for alert
+/* Implement the web app's default-hidden convention for alert
    elements.  Portico pages lack this CSS and thus show them by
    default. */
 .alert {
diff --git a/static/styles/components.css b/static/styles/components.css
index 52de5fb190..f7a14ad6c3 100644
--- a/static/styles/components.css
+++ b/static/styles/components.css
@@ -1,5 +1,5 @@
 /* Reusable, object-oriented CSS base components for all Zulip pages
-   (both webapp and portico). */
+   (both web app and portico). */
 
 .new-style {
     label.checkbox {
diff --git a/templates/corporate/jobs.html b/templates/corporate/jobs.html
index be6f82923e..3b5389e4c3 100644
--- a/templates/corporate/jobs.html
+++ b/templates/corporate/jobs.html
@@ -237,7 +237,7 @@
                     <li>You have the UI design skills to spot where a UI can be improved;
                         better yet, to design a better one.
                     </li>
-                    <li>You have experience doing large codebase migrations in webapps in a way
+                    <li>You have experience doing large codebase migrations in web apps in a way
                         that minimizes regressions.
                     </li>
                     <li>You have contributed to open-source projects; better yet, maintained a
diff --git a/templates/zerver/api/construct-narrow.md b/templates/zerver/api/construct-narrow.md
index e6d1d0bdd3..048c45104e 100644
--- a/templates/zerver/api/construct-narrow.md
+++ b/templates/zerver/api/construct-narrow.md
@@ -7,7 +7,7 @@ API (most importantly, in the API for fetching messages).
 
 It is simplest to explain the algorithm for encoding a search as a
 narrow using a single example.  Consider the following search query
-(written as it would be entered in the Zulip webapp's search box).  It
+(written as it would be entered in the Zulip web app's search box).  It
 filters for messages sent on stream `announce`, not sent by
 `iago@zulip.com`, and containing the phrase `cool sunglasses`:
 
diff --git a/templates/zerver/api/get-events.md b/templates/zerver/api/get-events.md
index 7c4b641677..fc9c328cc7 100644
--- a/templates/zerver/api/get-events.md
+++ b/templates/zerver/api/get-events.md
@@ -70,7 +70,7 @@ following error response:
 {generate_code_example|/events:get|fixture(400)}
 
 A compliant client will handle this error by re-initializing itself
-(e.g. a Zulip webapp browser window will reload in this case).
+(e.g. a Zulip web app browser window will reload in this case).
 
 See [the /register endpoint docs](/api/register-queue) for details on how to
 handle these correctly.
diff --git a/templates/zerver/api/register-queue.md b/templates/zerver/api/register-queue.md
index 8912885a30..1b669b3f90 100644
--- a/templates/zerver/api/register-queue.md
+++ b/templates/zerver/api/register-queue.md
@@ -28,7 +28,7 @@ Once the server garbage-collects your event queue, the server will
 with a code of `BAD_EVENT_QUEUE_ID` if you try to fetch events from
 the event queue.  Your software will need to handle that error
 condition by re-initializing itself (e.g. this is what triggers your
-browser reloading the Zulip webapp when your laptop comes back online
+browser reloading the Zulip web app when your laptop comes back online
 after being offline for more than 10 minutes).
 
 When prototyping with this API, we recommend first calling `register`
diff --git a/templates/zerver/api/writing-bots.md b/templates/zerver/api/writing-bots.md
index a13371c955..b0a7badc98 100644
--- a/templates/zerver/api/writing-bots.md
+++ b/templates/zerver/api/writing-bots.md
@@ -450,7 +450,7 @@ system and gives your test "dummy data" instead.
 
 Some bots, such as [Giphy](
 https://github.com/zulip/python-zulip-api/tree/master/zulip_bots/zulip_bots/bots/giphy),
-depend on a third-party service, such as the Giphy webapp, in order to work. Because
+depend on a third-party service, such as the Giphy web app, in order to work. Because
 we want our test suite to be reliable and not add load to these third-party APIs, tests
 for these services need to have "test fixtures": sample HTTP request/response pairs to
 be used by the tests. You can specify which one to use in your test code using the
diff --git a/templates/zerver/features.html b/templates/zerver/features.html
index ce76c1022b..9836dc5f94 100644
--- a/templates/zerver/features.html
+++ b/templates/zerver/features.html
@@ -273,7 +273,7 @@
         <a class="feature-block" href="/help/create-your-organization-profile" target="_blank" rel="noopener noreferrer">
             <h3>CUSTOM BRANDING</h3>
             <p>
-                Use your logo instead of Zulip’s in the desktop and webapp.
+                Use your logo instead of Zulip’s in the desktop and web app.
             </p>
         </a>
         <a class="feature-block" href="/integrations/communication" target="_blank" rel="noopener noreferrer">
diff --git a/templates/zerver/help/change-default-view.md b/templates/zerver/help/change-default-view.md
index a5abcd2f60..755eef51cd 100644
--- a/templates/zerver/help/change-default-view.md
+++ b/templates/zerver/help/change-default-view.md
@@ -1,7 +1,7 @@
 # Change default view
 
 The default view in Zulip (i.e. what view you reach after logging in
-to the Zulip webapp or hitting the `Esc` keyboard shortcut repeatedly)
+to the Zulip web app or hitting the `Esc` keyboard shortcut repeatedly)
 can be configured.  By default, **Recent topics** is the default view;
 the previous default, **All messages**, is also supported.
 
diff --git a/templates/zerver/help/gdpr-compliance.md b/templates/zerver/help/gdpr-compliance.md
index 3cb97ccfe6..425180688f 100644
--- a/templates/zerver/help/gdpr-compliance.md
+++ b/templates/zerver/help/gdpr-compliance.md
@@ -104,7 +104,7 @@ responding to a request from one of your users in relation to the
 GDPR:
 
 * A Zulip user can change their profile information, delete their
-  messages, uploaded files, etc., directly within the Zulip webapp.
+  messages, uploaded files, etc., directly within the Zulip web app.
 * You can use the [organization users](/#organization/user-list-admin)
   panel to deactivate users, edit or delete their account details,
   etc.
diff --git a/tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py b/tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py
index 73afc29897..025865d949 100644
--- a/tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py
+++ b/tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py
@@ -134,10 +134,10 @@ class BaseDocumentationSpider(scrapy.Spider):
         return callback
 
     def _make_requests(self, url: str) -> Iterator[Request]:
-        # These URLs are for Zulip's webapp, which with recent changes
+        # These URLs are for Zulip's web app, which with recent changes
         # can be accessible without logging into an account.  While we
-        # do crawl documentation served by the webapp (e.g. /help/),
-        # we don't want to crawl the webapp itself, so we exclude
+        # do crawl documentation served by the web app (e.g. /help/),
+        # we don't want to crawl the web app itself, so we exclude
         # these.
         if (
             url in ["http://localhost:9981/", "http://localhost:9981"]
diff --git a/tools/setup/emoji/build_emoji b/tools/setup/emoji/build_emoji
index 3f168a1554..e3a6d04f78 100755
--- a/tools/setup/emoji/build_emoji
+++ b/tools/setup/emoji/build_emoji
@@ -330,7 +330,7 @@ def setup_old_emoji_farm(
 
 def generate_map_files(cache_path: str, emoji_catalog: Dict[str, List[str]]) -> None:
     # This function generates the main data file about emoji that are
-    # consumed by the webapp, mobile apps, Markdown processor, etc.
+    # consumed by the web app, mobile apps, Markdown processor, etc.
     names = emoji_names_for_picker(EMOJI_NAME_MAPS)
     codepoint_to_name = generate_codepoint_to_name_map(EMOJI_NAME_MAPS)
     name_to_codepoint = generate_name_to_codepoint_map(EMOJI_NAME_MAPS)
diff --git a/zerver/lib/event_schema.py b/zerver/lib/event_schema.py
index 13559d12b5..3a29dcc1fd 100644
--- a/zerver/lib/event_schema.py
+++ b/zerver/lib/event_schema.py
@@ -4,7 +4,7 @@
 # By policy, every event generated by Zulip's API should be validated
 # by a test in test_events.py with a schema checker here (which is
 # validated, in turn, against the OpenAPI documentation for GET
-# /events in zulip.yaml and the fixtures used by the Zulip webapp
+# /events in zulip.yaml and the fixtures used by the Zulip web app
 # frontend).
 #
 # See https://zulip.readthedocs.io/en/latest/subsystems/events-system.html
diff --git a/zerver/lib/events.py b/zerver/lib/events.py
index b1a86d3973..29f280679c 100644
--- a/zerver/lib/events.py
+++ b/zerver/lib/events.py
@@ -107,7 +107,7 @@ def fetch_initial_state_data(
     include_streams: bool = True,
 ) -> Dict[str, Any]:
     """When `event_types` is None, fetches the core data powering the
-    webapp's `page_params` and `/api/v1/register` (for mobile/terminal
+    web app's `page_params` and `/api/v1/register` (for mobile/terminal
     apps).  Can also fetch a subset as determined by `event_types`.
 
     The user_profile=None code path is used for logged-out public
@@ -422,7 +422,7 @@ def fetch_initial_state_data(
 
     if want("stream"):
         if include_streams:
-            # The webapp doesn't use the data from here; instead,
+            # The web app doesn't use the data from here; instead,
             # it uses data from state["subscriptions"] and other
             # places.
             if user_profile is not None:
@@ -430,7 +430,7 @@ def fetch_initial_state_data(
                     user_profile, include_all_active=user_profile.is_realm_admin
                 )
             else:
-                # TODO: This line isn't used by the webapp because it
+                # TODO: This line isn't used by the web app because it
                 # gets these data via the `subscriptions` key; it will
                 # be used when the mobile apps support logged-out
                 # access.
diff --git a/zerver/lib/test_classes.py b/zerver/lib/test_classes.py
index 8de3adf770..a6fe72dba5 100644
--- a/zerver/lib/test_classes.py
+++ b/zerver/lib/test_classes.py
@@ -199,7 +199,7 @@ Output:
             # An API request; use mobile as the default user agent
             default_user_agent = "ZulipMobile/26.22.145 (iOS 10.3.1)"
         else:
-            # A webapp request; use a browser User-Agent string.
+            # A web app request; use a browser User-Agent string.
             default_user_agent = (
                 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                 + "AppleWebKit/537.36 (KHTML, like Gecko) "
@@ -494,7 +494,7 @@ Output:
         self.assert_json_error(result, assert_json_error_msg)
 
     def _get_page_params(self, result: HttpResponse) -> Dict[str, Any]:
-        """Helper for parsing page_params after fetching the webapp's home view."""
+        """Helper for parsing page_params after fetching the web app's home view."""
         doc = lxml.html.document_fromstring(result.content)
         [div] = doc.xpath("//div[@id='page-params']")
         page_params_json = div.get("data-params")
diff --git a/zerver/lib/widget.py b/zerver/lib/widget.py
index 323fd8e9c0..0bbf122547 100644
--- a/zerver/lib/widget.py
+++ b/zerver/lib/widget.py
@@ -46,7 +46,7 @@ def get_extra_data_from_widget_type(content: str, widget_type: Optional[str]) ->
 
 def do_widget_post_save_actions(send_request: SendMessageRequest) -> None:
     """
-    This code works with the webapp; mobile and other
+    This code works with the web app; mobile and other
     clients should also start supporting this soon.
     """
     message_content = send_request.message.content
diff --git a/zerver/models.py b/zerver/models.py
index 8cc57215ce..9ffa38b4c8 100644
--- a/zerver/models.py
+++ b/zerver/models.py
@@ -545,7 +545,7 @@ class Realm(models.Model):
     )
     icon_version: int = models.PositiveSmallIntegerField(default=1)
 
-    # Logo is the horizontal logo we show in top-left of webapp navbar UI.
+    # Logo is the horizontal logo we show in top-left of web app navbar UI.
     LOGO_DEFAULT = "D"
     LOGO_UPLOADED = "U"
     LOGO_SOURCES = (
@@ -1300,7 +1300,7 @@ class UserProfile(AbstractBaseUser, PermissionsMixin):
     # UI setting controlling Zulip's behavior of demoting in the sort
     # order and graying out streams with no recent traffic.  The
     # default behavior, automatic, enables this behavior once a user
-    # is subscribed to 30+ streams in the webapp.
+    # is subscribed to 30+ streams in the web app.
     DEMOTE_STREAMS_AUTOMATIC = 1
     DEMOTE_STREAMS_ALWAYS = 2
     DEMOTE_STREAMS_NEVER = 3
@@ -3080,7 +3080,7 @@ class UserPresence(models.Model):
 
     # The user was actively using this Zulip client as of `timestamp` (i.e.,
     # they had interacted with the client recently).  When the timestamp is
-    # itself recent, this is the green "active" status in the webapp.
+    # itself recent, this is the green "active" status in the web app.
     ACTIVE = 1
 
     # There had been no user activity (keyboard/mouse/etc.) on this client
diff --git a/zerver/openapi/zulip.yaml b/zerver/openapi/zulip.yaml
index 53863aa072..5f496e68cd 100644
--- a/zerver/openapi/zulip.yaml
+++ b/zerver/openapi/zulip.yaml
@@ -1757,7 +1757,7 @@ paths:
                                 the current user have changed (E.g. because the user dismissed one).
 
                                 Clients that feature a similar tutorial experience to the Zulip
-                                webapp may want to handle these events.
+                                web app may want to handle these events.
                               properties:
                                 id:
                                   $ref: "#/components/schemas/EventIdSchema"
@@ -1873,7 +1873,7 @@ paths:
                                     navigation and compose box state in response to the edit.  For
                                     example, if the user was previously in topic narrow, and the
                                     topic was edited with `change_later` or `change_all`, the Zulip
-                                    webapp will automatically navigate to the new topic narrow.
+                                    web app will automatically navigate to the new topic narrow.
                                     Similarly, a message being composed to the old topic should
                                     have its recipient changed to the new topic.
 
@@ -8085,7 +8085,7 @@ paths:
                           Present if `update_display_settings` is present in `fetch_event_types`.
 
                           Whether the user has chosen for the userlist to be displayed
-                          on the left side of the screen (for desktop app and webapp) in narrow
+                          on the left side of the screen (for desktop app and web app) in narrow
                           windows.
 
                           See [PATCH /settings/display](/api/update-display-settings)
@@ -9550,7 +9550,7 @@ paths:
           in: query
           description: |
             Whether to use the [maximum available screen width](/help/enable-full-width-display)
-            for the webapp's center panel (message feed, recent topics) on wide screens.
+            for the web app's center panel (message feed, recent topics) on wide screens.
           schema:
             type: boolean
           example: true
@@ -9608,7 +9608,7 @@ paths:
           in: query
           description: |
             The [default view](/help/change-default-view) used when opening a new
-            Zulip webapp window or hitting the `Esc` keyboard shortcut repeatedly.
+            Zulip web app window or hitting the `Esc` keyboard shortcut repeatedly.
 
             * "recent_topics" - Recent topics view
             * "all_messages" - All messages view
diff --git a/zerver/tests/test_auth_backends.py b/zerver/tests/test_auth_backends.py
index a745872a2d..c32b80ba12 100644
--- a/zerver/tests/test_auth_backends.py
+++ b/zerver/tests/test_auth_backends.py
@@ -918,7 +918,7 @@ class SocialAuthBase(DesktopFlowTestingLib, ZulipTestCase):
           "Continue to registration" if you try to log in using an
           account that doesn't exist but is allowed to sign up.
         * next: Parameter passed through in production authentication
-          to redirect the user to (e.g.) the specific page in the webapp
+          to redirect the user to (e.g.) the specific page in the web app
           that they clicked a link to before being presented with the login
           page.
         * expect_choose_email_screen: Some social auth backends, like
diff --git a/zerver/tests/test_messages.py b/zerver/tests/test_messages.py
index 07d9d28db7..2b2d40f9cb 100644
--- a/zerver/tests/test_messages.py
+++ b/zerver/tests/test_messages.py
@@ -55,7 +55,7 @@ class MissedMessageTest(ZulipTestCase):
         set_presence(hamlet, "iPhone", ago=5000)
         assert_missing([hamlet.id])
 
-        set_presence(hamlet, "webapp", ago=15)
+        set_presence(hamlet, "website", ago=15)
         assert_missing([])
 
         message_type = "private"
diff --git a/zerver/views/auth.py b/zerver/views/auth.py
index 7ef4175177..5979e9f60d 100644
--- a/zerver/views/auth.py
+++ b/zerver/views/auth.py
@@ -142,7 +142,7 @@ def maybe_send_to_registration(
     # result in being logged into the app to persist if the user makes
     # mistakes while trying to authenticate (E.g. clicks the wrong
     # Google account, hits back, etc.) during a given browser session,
-    # rather than just logging into the webapp in the target browser.
+    # rather than just logging into the web app in the target browser.
     #
     # We can't use our usual pre-account-creation state storage
     # approach of putting something in PreregistrationUser, because
diff --git a/zerver/views/message_fetch.py b/zerver/views/message_fetch.py
index 1b07a21e5a..f71cc93f4f 100644
--- a/zerver/views/message_fetch.py
+++ b/zerver/views/message_fetch.py
@@ -918,7 +918,7 @@ def parse_anchor_value(anchor_val: Optional[str], use_first_unread_anchor: bool)
         # We don't use `.isnumeric()` to support negative numbers for
         # anchor.  We don't recommend it in the API (if you want the
         # very first message, use 0 or 1), but it used to be supported
-        # and was used by the webapp, so we need to continue
+        # and was used by the web app, so we need to continue
         # supporting it for backwards-compatibility
         anchor = int(anchor_val)
         if anchor < 0:
diff --git a/zerver/views/presence.py b/zerver/views/presence.py
index 66c48182b3..79becf5d08 100644
--- a/zerver/views/presence.py
+++ b/zerver/views/presence.py
@@ -25,7 +25,7 @@ from zerver.models import (
 def get_presence_backend(
     request: HttpRequest, user_profile: UserProfile, user_id_or_email: str
 ) -> HttpResponse:
-    # This isn't used by the webapp; it's available for API use by
+    # This isn't used by the web app; it's available for API use by
     # bots and other clients.  We may want to add slim_presence
     # support for it (or just migrate its API wholesale) later.
 
@@ -127,7 +127,7 @@ def update_active_status_backend(
 
 
 def get_statuses_for_realm(request: HttpRequest, user_profile: UserProfile) -> HttpResponse:
-    # This isn't used by the webapp; it's available for API use by
+    # This isn't used by the web app; it's available for API use by
     # bots and other clients.  We may want to add slim_presence
     # support for it (or just migrate its API wholesale) later.
     return json_success(get_presence_response(user_profile, slim_presence=False))
diff --git a/zproject/urls.py b/zproject/urls.py
index a2064d337e..6feb996035 100644
--- a/zproject/urls.py
+++ b/zproject/urls.py
@@ -398,7 +398,7 @@ v1_api_and_json_patterns = [
         POST=(
             mark_hotspot_as_read,
             # This endpoint is low priority for documentation as
-            # it is part of the webapp-specific tutorial.
+            # it is part of the web app-specific tutorial.
             {"intentionally_undocumented"},
         ),
     ),
@@ -472,7 +472,7 @@ v1_api_and_json_patterns = [
     # report -> zerver.views.report
     #
     # These endpoints are for internal error/performance reporting
-    # from the browser to the webapp, and we don't expect to ever
+    # from the browser to the web app, and we don't expect to ever
     # include in our API documentation.
     rest_path(
         "report/error",