Chatwork app vs browser: what actually differs

Chatwork sits in a browser tab all day, and at some point the question comes up: is there a reason to install the desktop build instead. Most comparison articles answer it with feel. The app is snappier, the notifications land more reliably, the window looks tidier. None of that survives contact with the actual documentation, because the desktop build is a wrapper around the same web application, and the vendor publishes an explicit list of what stops working inside it.

That list is the real answer. The desktop build adds three capabilities and removes four, and which side hurts more depends entirely on whether browser extensions are part of how the work gets done.

Two doors into the same room

Chatwork runs from a browser at any supported version, or from a downloadable desktop build for Windows and macOS. Messages, tasks, files, and contacts all live on the account, so nothing changes about what is visible when switching between them. There is no data migration and no export step.

What changes is the container. In a browser tab, Chatwork inherits everything the browser provides: extensions, the full context menu, font control, the browser's own proxy handling, and the browser's update cycle. In the desktop build, Chatwork gets a dedicated window, a Dock icon, and a set of features that only exist because the vendor wrote them into that build.

The vendor here is kubell. The company changed its legal name from Chatwork Co., Ltd. to kubell on July 1, 2024, while the product kept the Chatwork name. That is worth knowing before reading older comparison articles, because the mismatch in company names makes some of them look like they are describing a different service. The product was not discontinued, registration was not closed, and pricing tiers were not folded into each other.

What only the desktop build does

The download page lists the desktop build's advantages in a single paragraph, and there are three of them.

Simultaneous login to multiple Chatwork accounts. This is the one that decides the question for a lot of people. Anyone running a company account alongside a personal or client-specific account faces a logout and login cycle in a single browser profile. The desktop build holds several accounts open at once.

Second, other communication services can be pinned into the same window. The download page names Gmail and Zoom in the Japanese edition and Gmail and Skype in the English edition, added as tabs along the top bar so the Chatwork window doubles as a small workspace.

Third, a screenshot function. It clips a region of the screen and hands it straight to a message. The English download page states plainly that these functions are only available on the desktop version of the app, so none of the three can be reproduced by staying in the browser.

If the account count is one, no other service needs to live in the same window, and screenshots already come from a keyboard shortcut, then all three land on nothing.

What stops working inside the desktop build

The help center carries a table of restricted features, and the first row is the significant one. Browser extensions do not run, because extensions depend on browser machinery the desktop build does not expose.

The same table lists three more unavailable items: font selection is not configurable, previews of external services that require a login (Google Docs is the named example) generally do not render in the timeline, and use behind an authenticated proxy is not currently supported.

A second table covers features that work with caveats. The right-click context menu is reduced to simple operations such as copy and paste rather than the full browser menu. Text typed and left unsent survives while the app stays resident but not after a full quit. Account settings and administrator settings open in a browser rather than in the app, which means a separate browser session logged into the same account is still required for those screens. Single sign-on through SAML may misbehave depending on the identity provider, and third-party integrations may lose functionality depending on the partner's own policy.

That last group is easy to miss when the decision is made on first impressions. The desktop build does not remove the browser from the workflow. It just moves the browser to the moments when settings need changing.

The version floors decide some cases outright

Before any of the feature comparison matters, the machine has to be eligible. The published requirements are narrow enough to end the discussion for some readers.

Route	Requirement
Desktop build, macOS	macOS 12 (Monterey) or higher, Intel and Apple silicon both supported
Desktop build, Windows	Windows 10 or higher
Browser	Latest Google Chrome, Firefox, Safari, or Chromium-based Microsoft Edge
Internet Explorer	Support ended September 22, 2021

A Mac on macOS 11 or older cannot run the desktop build at all. A managed work Mac without administrator rights cannot install it either. A network that routes through an authenticated proxy is explicitly outside what the desktop build supports. In each of those cases the browser is not the fallback, it is the only route, and the remaining question is what kind of window to put it in.

The browser side is deliberately permissive by comparison. Any current release of the four named browsers qualifies, and browsers update on their own schedule rather than waiting for an installer.

Plan limits are not container limits

One frequent source of confusion is worth clearing up here, because it sends people to the download page for the wrong reason. The published free plan restricts message history to the most recent 40 days, caps an organization at 100 users, allocates 10 GB of storage per organization, and allows 20 contacts outside the organization per user. Paid tiers lift those ceilings, with the standard tier at 700 yen per user per month before tax on an annual contract and the professional tier at 1,200 yen on the same terms.

Every one of those numbers belongs to the plan, not to the container. Installing the desktop build does not extend the 40 day history, raise the storage allocation, or add contacts. Anyone who hit a wall and went looking for the app expecting relief will find the same wall inside it.

Why the advice online contradicts itself

Three things make older articles unreliable on this topic.

The company rename is the first. Text written before July 2024 refers to a company that no longer carries that name, which reads as a stale or wrong source even when the product details are still accurate.

The second is that behavior has changed inside the desktop build itself. The help center notes that starting from desktop app version 2.4.0, the app no longer launches automatically at startup on Windows. Articles that warn about an app forcing itself into the startup sequence are describing an older build.

The third is that the browser caught up. Complaints about browser notifications not arriving, or about the tab going quiet in the background, date from an era when that was genuinely true. A current browser delivers web notifications to the operating system's notification center and keeps a background tab connected. The gap that remains is the feature gap listed above, not a reliability gap.

Reading the download page and the restricted-features help article directly takes about five minutes and settles every point in this comparison.

A third container that keeps the extensions

Laid out plainly, the common situation is this: one or two accounts, extensions that are part of the job, and a strong desire to stop hunting for Chatwork among thirty tabs. The two official routes each fail one of those three.

A third route exists. A tool that turns a website into a standalone Mac app can build a small application that opens exactly one URL. The important detail is what sits underneath it. Rather than bundling a browser engine of its own, this kind of tool builds on the browser already installed on the machine, so the engine, the update cycle, the extensions, and the logged-in session all carry over unchanged.

The result behaves like any other application. It takes a place in the Dock, appears in the Cmd+Tab list, gets its own Mission Control window, and stays open when the browser quits. Chrome and Chromium-based Edge both appear on Chatwork's own list of recommended browsers, so choosing either as the base keeps the supported-environment requirement satisfied while removing the tab problem. Chatwork is one of the services that ships as a ready-made preset, which means the URL, the icon, and the app name are already paired together rather than typed in by hand. The full list is on the supported services page, and the build steps are in the guide.

Running two accounts without the desktop build

Simultaneous login is the desktop build's strongest argument, and it is worth knowing that the third route reaches the same outcome by a different mechanism.

Each app created this way gets its own browser profile. Cookies, sessions, history, and cache are separated per app rather than shared. Building two apps from the same Chatwork URL produces two independent logins that sit side by side in the Dock, and signing out of one leaves the other untouched. Nothing about the browser's own logged-in state is disturbed either, so a personal Google session in the main browser stays separate from a work account inside the app.

Extensions are toggled per app as well. A translation extension can live only in the app used with overseas clients, while the internal app runs without it. That combination is not available in the official desktop build at all, since extensions do not run there in the first place.

Notifications need one action after the app is built. The web version of Chatwork asks for notification permission on first load, and granting it inside the app window registers the permission under the app's own name in macOS rather than under the browser. From then on, notification style and sound are adjusted per app in System Settings like any native application. The scope of what separates and what does not is listed under features.

What to change first

Start with eligibility rather than preference. A Mac below macOS 12, a machine without install rights, or a network behind an authenticated proxy removes the desktop build from consideration, and the only remaining decision is what kind of window the browser version lives in.

If the machine is eligible, the question narrows to one trade: extensions or pinned service tabs. Anyone whose translation, password, or blocking extensions are part of daily work should keep the browser engine and give Chatwork a window of its own. Anyone who wants Gmail and Zoom sitting in the same frame as Chatwork should install the official desktop build and accept the extension loss.

Open the browser version, check whether the extensions in the toolbar are ones the work depends on, and let that single observation pick the route.