Converse.js: a client-side XMPP chat client you embed in a web page

What Converse.js actually is, and who it is for

The README describes Converse as a "100% client-side XMPP chat app that runs in a web browser". That single phrase sets the boundary of the project. There is no server component, no account database, no message store. Every message travels through an XMPP server you already run, and the browser holds the session. If you do not have a Jabber server, Converse.js cannot give you one.

The audience follows from that. It fits teams that run Prosody, Openfire or another XMPP server and want a chat surface inside a product, an intranet, or a support page. The README lists three display modes: fullpage, which behaves as a single-page application covering the viewport; overlay, where chat boxes float above your existing site; and embedded, which mounts into a specific element in your page's DOM. That range is the reason to pick it over a standalone desktop client. A documentation site can drop in a single room with the embedded mode, while an internal tool can take the fullpage mode and never write chat UI code.

It is not a Slack replacement in the sense of bundling identity, storage and search. Converse is the visible layer. Everything behind it is XMPP, and the feature set you get depends on what your server supports.

How the client connects: XMPP over WebSocket, BOSH and the XEP list

A browser cannot open a raw TCP connection to an XMPP server, so Converse uses the transports XMPP defines for web clients. The README's XEP table lists RFC-7395, the XMPP subprotocol for WebSocket, and XEP-0124, BOSH. Those are the two ways the client reaches a server from a page. XEP-0156, discovering alternative XMPP connection methods, is also listed, which is how a client finds the right endpoint without hardcoding it.

On top of the transport, the table covers the extensions that produce visible features. XEP-0045 gives multi-user chat rooms. XEP-0184 provides message receipts. XEP-0085 covers chat state notifications, the typing indicator. XEP-0048 handles bookmarks, so rooms persist across sessions. XEP-0077 allows in-band registration, and the README notes anonymous login works "server permitting", which is a server-side decision rather than a client one. Two entries are marked "Limited support": XEP-0060, publish-subscribe, and XEP-0163, personal eventing protocol. That qualifier is worth reading literally. If your design depends on pubsub-driven features, the client's coverage is partial.

The architecture is a JavaScript bundle with a plugin system built on pluggable.js, which the README names directly. Extending behaviour means writing a plugin against that system rather than patching the core. The package also declares npm workspaces for src/headless and src/log, so part of the codebase is consumable outside the browser bundle.

Install Converse.js from source and open the dev page

The README's quick start clones the repository, pulls the media repository for images such as sponsorship logos, installs dependencies, builds, and starts a server on port 8008.

git clone [email protected]:conversejs/converse.js.git
cd converse.js
git clone https://github.com/conversejs/media.git media; // To see images like sponsorship logos
npm install
npm run build
npm run serve -- -p 8008

After that, the README says to open http://localhost:8008/dev.html. That page is the development entry point, not the production bundle. The repository also ships fullscreen.html and local.html at the top level, and a demo directory containing anonymous.html, embedded.html and index.html. The embedded.html file is the one to read if you plan to mount chat into part of an existing page, because it shows the pattern the project itself uses.

If you would rather not build anything, the README points at a hosted app at conversejs.org/fullscreen.html, and at prebuilt desktop packages: Converse Desktop and Converse Tauri, both linked from their own release pages. The Makefile exposes the same workflow under different names, with targets including all, dist, dev, devserver, check, doc, po and pot, and it documents HTTPSERVE_PORT defaulting to 8008, which matches the npm serve port in the README.

Where Converse.js is the wrong tool

The clearest limitation is the one stated in the project's own description: it is client-side. If your requirement is a hosted chat product where you create users, store history and search it later, Converse gives you none of that. Message history in XMPP lives in server archives, and the README's XEP table does not list message archiving management among the extensions. What you can retrieve depends on the server.

Encryption follows the same pattern. OMEMO is listed as a key feature and appears in the repository topics. It is end-to-end encryption between clients, which also means server-side search and compliance tooling cannot read the content. A regulated environment that needs server-side retention and inspection will find OMEMO working against that goal. You can run without it, but then you are trusting the server with plaintext.

Two smaller constraints matter in practice. First, the pubsub and personal eventing entries carry the "Limited support" note, so features built on those extensions may not behave as a specification reader would expect. Second, the client is a JavaScript bundle that runs in the user's browser, so anything you configure there is visible to the user. Credentials, server addresses and any tokens you pass into the configuration are not secrets in that context.

How it compares with a server-side web chat

The obvious alternative is a chat product where the web client is served by the same application that stores the data. In that model the browser talks to your backend over HTTP, your backend holds accounts and history, and the protocol between browser and server is yours to define. Converse.js inverts this. The browser speaks XMPP directly to an XMPP server, and your application is not in the message path at all.

The practical difference shows up when you want to add a feature. With a server-side chat, adding a message type means a database change and an API change. With Converse.js, it means either a server-side XMPP component or a client plugin written against pluggable.js. That is more work up front and less work later if you are already invested in XMPP, because the federation and multi-user chat semantics come from the protocol rather than from your own code. The trade is real in both directions.

A second alternative is a desktop XMPP client. Converse.js is not competing there; the project itself publishes Converse Desktop and Converse Tauri for users who want an installed app. The web client exists for the case where installing software is not an option, such as a public support page or a shared terminal.

Licence, releases and what upgrades cost

Converse.js is licensed under MPL-2.0, and the repository carries LICENSE, LICENSE.txt and COPYRIGHT files. MPL-2.0 is file-level copyleft: modifications to covered files stay under the same licence, while larger works that combine the library with other code are treated differently from a strong copyleft licence. That is a general description of the licence family, not legal advice, and the COPYRIGHT file is the place to read for the project's own attribution requirements.

The release history shows a 14.0.0 line, with v14.0.0 published on 2026-06-26 and three betas in the days before it. The last push to the repository was on 2026-09-16, so the project is being worked on rather than frozen. The Makefile documents an NPM_TAG variable defaulting to latest, with a comment noting that pre-releases should override it to keep the latest tag on the stable line. That tells you the maintainers run pre-release cuts through the same publish path, so pinning an exact version rather than a tag is the safer choice for a deployment.

Upgrade cost is dominated by the XEP surface and the plugin API. A major version bump can change configuration options or plugin hooks, and because the client is embedded in your page, a breaking change lands in your application rather than behind a server you control. The CHANGES.md file at the repository root is where release notes are kept, and it is the first thing to read before moving a pinned version.

Editorial conclusion

Adopt Converse.js if you already operate an XMPP server and need chat inside a web page, especially if OMEMO encryption or multi-user rooms matter to you. Do not adopt it if you have no XMPP infrastructure, or if you expect the library to supply accounts and message storage; it is a client only. Before committing, check that your server supports the XEPs your feature list depends on, confirm which release line you are pinning, and read the configuration documentation for the display mode you intend to use.

Frequently asked questions

Official sources

1. conversejs/converse.js on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases