Notion web vs the desktop app: what actually differs

Most comparisons of Notion in a browser and Notion as an installed application list features that both sides have, which explains why the question keeps coming back. The pages, the databases, the permissions and the plan all live in the same account, so nothing inside the page is in dispute. What differs is the frame around the page, and that frame changes four concrete things: what hardware is allowed to run it, when a new version arrives, what happens when someone clicks a link to a Notion page, and whether Notion can be summoned without leaving the current window. Those four are worth deciding once.

The account is the same on both sides

Notion's help centre treats the browser as one of its apps rather than as a lesser version of the product. The section is called Notion on desktop, web, and mobile, and the web page in it describes Notion as a cloud based app that can be reached from various web browsers, with content syncing automatically as long as there is a connection.

The practical consequence is that switching is cheap. There is no export, no local database to move, no settings file that lives on one machine. Someone who installs the desktop app on Monday and deletes it on Friday loses nothing except the icon. That makes a week long trial a better way to decide than reading a feature matrix, because the differences that matter show up as small daily friction rather than as missing capabilities.

It also means the honest framing of the question is not which one is more powerful. Both render the same workspace. The framing is which one should own the Dock, the keyboard shortcut, and the link handling on this particular machine.

One more thing gets confused in these conversations. Notion Calendar and Notion Mail are separate entries in the help centre and separate pieces of software. When a colleague says they installed the Notion app, the follow up question is which one, because the answer changes everything after it.

The desktop app adds a way in from outside Notion

The strongest argument for installing is not the window. It is Command Search. On desktop, search and Notion AI can be triggered from a customisable keyboard shortcut, from the menu bar on Mac, or from the task bar on Windows, without switching to the Notion window or bringing it to the front. The help pages state that this is turned on by default, and that turning it off is a toggle under Settings, then Preferences.

Two related defaults come with it. Notion is set to open at login when the desktop app is installed, and on a Mac that is removed by right clicking the Dock icon, choosing Options, and unchecking Open at Login. Every new tab opens a search window by default rather than a page, which is also a toggle under Preferences called Open Search when creating a new tab. Turning that off makes new tabs open whatever the On Start up setting points to.

The rest of the desktop advantages are smaller but add up over a day. Tabs inside the app hold only Notion pages, so there is no competition from unrelated sites. Hovering over a tab previews the page inside it. Push notifications arrive at the operating system level when someone mentions the reader, assigns a task, or a reminder fires.

None of that is available to a browser tab, and it is the real dividing line. A tab requires switching to the browser, finding the right window, then finding the right tab. Command Search removes all three steps. If a workspace is opened five times a day for thirty seconds each, that difference decides the question on its own.

Requirements are written in two different units

The system requirements page splits by platform, and the units are not comparable. Desktop is stated as an operating system version: macOS 12 or above, Windows 10 version 21H2 or above, or Windows Server 2016. Web is stated as a browser generation: the last eight major Extended stable releases for Chrome, and the last two major releases for Firefox, Safari and Edge. Mobile is stated as iOS 17 or above and Android 8 or above.

That difference decides what happens to an ageing machine. A requirement pinned to the operating system freezes the moment the machine stops receiving major updates. A requirement pinned to browser generations keeps being met for as long as the browser itself keeps updating, which on Windows and on macOS with a third party browser is considerably longer than the hardware's own support window. The reverse case exists too. In a managed environment where browser updates are held back for testing, the browser route can fall out of support first.

Two more facts belong in the same section. Notion's FAQ states plainly that there is no Linux app at the moment and points Linux users to Chrome, Firefox or Safari, so on Linux the browser is not a preference, it is the only route. And on Mac, downloading the wrong processor build produces an error saying the application is not supported on this Mac. The fix is to uninstall, check the processor under About This Mac, and install the matching build.

Three switches decide where a link opens

This is the part that produces the most support questions, because the behaviour is not controlled in one place. Clicking a link to a Notion page can land in the browser or in the installed app, and three separate settings vote on the outcome.

The first lives in Notion on the web, under Settings and then Preferences, as Open links in desktop app. The second lives in the desktop app, under Settings and then Preferences, as Open Notion links in browser. These point in opposite directions, and having both switched on is how people end up with links that behave differently depending on where they were clicked. The third is outside Notion entirely. The help pages note that if Notion's own settings are already set to open links in a browser and the desktop app keeps launching anyway, device level settings may be overriding Notion's settings.

Windows added a fourth wrinkle with the MSIX package. In that build, link handling is managed through Windows Settings under Apps for websites rather than inside Notion, and start at login is managed there as well. The upside stated for MSIX is a cleaner install and uninstall and easier deployment for IT teams, with existing profile and login data carried over.

There is also a manual override worth knowing. Opening a Notion page in a browser, clicking the three dots at the top right, and scrolling to Open in Mac app forces that one page across without changing any global setting. That is the fastest way to test whether the app is installed and reachable at all.

The order in which these are set matters more than the settings themselves. Turning on Open links in desktop app while Open Notion links in browser is still on in the app produces a loop where a click bounces between the two. Notion's own instructions handle this by naming both: switch the web preference on, then confirm the app preference is off. Anyone writing an onboarding document for a team should copy that pairing rather than describing one switch, because a colleague who sets only half of it will report the feature as broken.

Updates arrive on different schedules, and IT can hold them

In a browser, the version served is the version loaded. There is no update step and no version drift between colleagues.

The installed app updates automatically, but automatically has a schedule. To check manually, the Notion menu on Mac and the File menu on Windows both have Check for Updates, and pressing alt reveals the menu bar if it is hidden. Clicking the question mark in the left sidebar and then More shows the last time the app updated. If several days have passed with no update, refreshing with cmd or ctrl and R usually forces one, and Notion notes that a reinstall is very rarely needed.

The detail that matters for company machines is this: IT departments can manage update settings for the macOS desktop app through their deployment process. So when a guide describes a menu item that is not there, the cause may be neither a bug nor a stale article. Opening the same page in a browser, where the latest version is always served, separates the two possibilities in one step.

	Browser tab	Installed desktop app
Requirement stated as	Browser generation	macOS 12 or above, Windows 10 21H2 or above
Linux	Supported route	No app available
Version drift between colleagues	None	Possible, and IT can manage it on macOS
Global search from outside the app	No	Command Search, with a shortcut and menu bar entry
Own Dock icon and app switcher entry	No	Yes
Open at login	Not applicable	On by default, removable
Where link handling is decided	Web setting	App setting, plus device level, plus Windows Apps for websites on MSIX

A third route that sits between the two

There is a route neither column covers: building a standalone Mac application from the website itself. The window is a browser window with the browser removed from view, so it gets a Dock icon, a name, an icon and its own entry in the application switcher, without requiring the vendor to have shipped a desktop build.

Three things follow from that. It runs wherever the browser runs, which puts macOS versions below the desktop app's floor back in play. It keeps the extensions and the signed in session of the browser it is built from, because it borrows an engine already installed rather than bundling its own. And one bundle can be made per workspace or per account, which is the usual reason people want two windows open at once. The Features page describes what a bundle carries, and the Guide walks through building one.

What it cannot do is add operating system integration that the site does not offer. There is no equivalent of Command Search, because that is code running outside the web page. Anyone who wants a global hotkey should install the official app and stop there. Anyone who wants the workspace out of the tab strip, on a machine or in a configuration the official app does not cover, is in the other case. The Supported services list shows how many everyday tools fall into that second group, mostly internal dashboards and admin panels that will never get a native build.

What to change first

Check the operating system version first, because it removes options rather than adding them. On a supported version, install the desktop app, leave Command Search on for a week, and judge it on how often the shortcut gets used rather than on the window. If the answer is rarely, uninstall it and set the web preference to keep links in the browser, or build a single named window with Kagemusha so the workspace has a Dock icon without a second update channel to manage.