XMPP vs WebSocket: Which is best for chat apps?

Extensible Messaging and Presence Protocol (XMPP) is a realtime messaging protocol originally created in the late 90’s to provide an open-source alternative to the closed messenger apps of the time. This means that anyone can implement an XMPP service. More recently it has been standardized by the Internet Engineering Task Force (IETF), and it has become a popular choice for messaging apps. Today it is used by the likes of WhatsApp and Converse. 

A notable characteristic of XMPP is that it describes the format and behavior of the communication, but it does not strictly define the transport by which messages are sent around the network. By default XMPP uses TCP as the transport protocol to transmit XML (Extensible Markup Language) data between network endpoints. Certain corporate firewalls block message transmission when using TCP. To overcome this problem, the XMPP community developed an HTTP transport that can be used as a fallback.

XMPP can also use WebSockets for transport. Using XMPP with WebSockets presents limitations, however, as XMPP is not optimized for transport speed like WebSockets.

XMPP also doesn’t support binary data transmission - only textual data in an XML format. Speaking of XML, its syntax is verbose and redundant compared to other text-based data transmission formats (e.g., JSON). This can lead to increased storage costs and transportation overhead when large volumes of data are involved.

Despite these shortcomings, XMPP has gained popularity because it is highly extensible, with a rich plugin community. You can employ extensions to support asynchronous messaging, pub/sub systems, signaling for VoIP, video, file transfer, gaming, and Internet of Things (IoT) applications including the smart grid and social networking services.

XMPP was also designed with messaging apps in mind, and it comes with a solid sense of user identity by default. For example, every client on an XMPP network is allocated an XMPP address (JabberID) to identify them. This address works just like a standard email address with an IP address/domain name, an optional node, and a username for the resident server.

XMPP uses a client-server architecture. Messages are routed between clients via servers, rather than directly between clients. XMPP uses a decentralized server architecture — there doesn’t have to be one single server, and developers can create their own servers to handle message routing.

The architecture can also feature XMPP gateways — these sit in between XMPP servers and servers that handle other protocols (such as SMS and SMTP) and provide translation capabilities. This means that you can create services that allow people to communicate between different message types — SMS, email, XMPP, and others.

At the moment, XMPP does not support Quality of Service (QoS); assured delivery and ordering of messages has to be built on top of the XMPP layer.

A diagram that shows how XMPP works and its architecture

This open architectural style contributes significantly to XMPP’s flexibility and extensibility, with control of a system able to be shared between multiple owners, and the ability to pull in different messaging formats.

The core XMPP specifications feature multiple levels of security:

• Simple Authentication and Security Layer (SASL) for secure connection authentication and data security in Internet protocols.

• Point-to-point encryption (TLS) and multi-end-to-end encryption (OMEMO) for secure data transmission.

You get a lot of security for free, making XMPP a good choice if you want to build apps without having to implement the security features yourself.

There are a wide variety of libraries available for building XMPP platforms in various different programming languages — .NET, Python, Java (including Android), C++, Swift, Rust, and more. You can find a detailed list at XMPP Libraries & Tools.

You can also find several different clients that work on all manner of different platforms; see XMPP Clients.

• XML data messaging format

• Rich plugin community

• Written with messaging in mind; provides client IDs by default

• Decentralized client-server architecture

• XMPP gateways for translation between XMPP and other message formats

• Multi-layer security by default

XMPP pros

• Maturity: XMPP is a very mature protocol, with solid community support, meaning that a lot of help is available.

• Extensibility: XMPP has a lot of extensions available, meaning less to implement yourself.

• Security: High level of security available out of the box — it is good to not have to worry about such critical functionality.

• Flexibility: Compatible with other messaging formats via XMPP gateways, meaning that you can translate between SMS, SMTP, etc., and XMPP.

• Decentralized architecture: This allows more control by different users of a service, and the creation of multiple controlling servers rather than it all being controlled in one place.

• Messaging suitability: XMPP was originally designed more with messaging apps in mind. You get features such as client IDs out of the box, again meaning fewer features to code yourself.

XMPP cons

• Data format limitations: No support for binary data transmission, which can be a major limitation. Additionally, XMPP uses XML under the hood, a verbose data format that is definitely less memory efficient compared to lightweight alternatives like JSON and MessagePack.  

• Speed: Message delivery is slower than WebSockets, and XMPP connections are not persistent. This is a limitation if you are expecting high message throughput.

• Firewall blocking: Some corporate firewalls can block message transmission. To overcome this problem, the XMPP community developed an HTTP transport that can be fallen back to if needed.

• Lack of messaging guarantees: At the moment, XMPP does not support messaging QoS; data integrity (guaranteed ordering and delivery) has to be built on top of the XMPP layer.

WebSocket is a thin transport layer built on top of a device's TCP/IP stack, which provides full-duplex, low-latency, event-driven connections between the server and the browser. WebSockets are a more recent technology than XMPP; RFC 6455 – The WebSocket Protocol was published by the IETF in 2011. Popular WebSocket-based apps include Trello, Slack, and Discord.

WebSockets support the transmission of any text or binary data type, and there are no hard limits on concurrent connections, making WebSockets scalability less of a pressing concern than XMPP. In addition, message transmission is much faster than XMPP.

WebSocket also has a rich community, with many libraries and extensions available such as gzip compression in messages and IoT application compatibility. You can also declare subprotocols to define what messaging protocol should be used (MQTT, SOAP, WAMP, etc.). Websocket can even declare XMPP as a subprotocol if you want to send XMPP’s XML format across the two. Many WebSocket-based solutions use pub/sub to help with scalability.

Like XMPP, WebSockets also have issues with certain corporate firewalls blocking message transmission, so HTTP fallback can be required with WebSockets too. Many WebSocket libraries (such as Socket.IO) provide HTTP fallbacks largely for this reason.

WebSocket uses a client-server architecture. Messages are routed between clients via servers, rather than directly between clients. WebSockets uses a centralized server architecture — there is generally a single controlling system for each application to handle message routing, connected to by clients by specifying the URL endpoint of the server.

After the initial HTTP handshake, a single WebSocket connection can handle all of the messages for a single session and will persist until it is closed.

WebSocket supports quality of service out of the box: Message delivery and order is assured.

WebSocket security is not as mature as that of XMPP — you don’t get identity and authentication features for free and would need to provide those yourself. Because of the nature of WebSockets, you can use TLS for secure data transmission.

In terms of building WebSocket silutions, there is support available in a variety of languages, for example JavaScript (socket.IO, SockJS), .NET (SignalR), Java (ServerSocket, Jetty), Python (websocket-client), and more.

In terms of clients, all major browsers now support the WebSocket API for connecting to WebSocket servers. See the WebSockets browser support table on MDN for more details. There are also clients available for native platforms — Windows, macOS, Linux, Android, iOS.

• Thin transport layer built on top of a device's TCP/IP stack, providing full-duplex, low-latency, event-driven connections

• Text and binary data messaging formats

• Extensibility via extensions and subprotocols

• A more general-purpose solution for various realtime use cases

• Centralized client-server architecture

• Supports a variety of protocols — SOAP, MQTT, WAMP, and even XMPP

• Simple TLS security by default

WebSockets pros:

• Speed: A single WebSocket connection can handle all of the messages for a single session, the connection is persistent, and the transmission speed is faster than XMPP.

• Data format flexibility: WebSockets can transmit binary data and UTF-8 meaning that apps can support sending plain text and binary formats such as images and video. 

• Connection limits: The number of concurrent connections between client and server is much less limited than with XMPP.

• Support for data integrity: Message delivery and ordering are assured.

WebSocket cons:

• Firewall blocking: Some enterprise firewalls with packet inspection have trouble dealing with WebSockets (notably SophosXG Firewall, WatchGuard, McAfee Web Gateway).

• No built-in support for reconnection: When a WebSocket connection is closed (e.g. due to network issues), the client does not try to reconnect to the server, which means you’ll need to write extra code to poll the server, re-establishing the connection when it is available again. Alternatively, you could use a library with reconnection support like Socket.IO.

• Extensibility: There are a wide variety of libraries available for building WebSocket apps, and it does have some extensions available, but it is not as extensible as XMPP.

• Security: WebSockets are not quite as secure as XMPP out of the box. You’ll have to put together solutions for features like authentication yourself, or use a library.

• Messaging suitability: WebSockets is a more general solution; you get less messaging features by default than with XMPP.

• Maturity: WebSockets is not as mature as XMPP, although it does arguably have better support on the web platform (for example native browser support).

• Centralized architecture: WebSockets is not quite as open as XMPP, which may or may not be a problem depending on your use case.

The following table provides a quick summary of the key differences between XMPP and WebSockets.

XMPP and WebSockets are both strong contenders for building chat applications or, to put it another way, applications involving messaging components of one kind or another. Which technology to use depends on a few key factors.

XMPP is an older, more mature technology. While it is more limited than WebSockets in some ways (for example by not supporting binary data transmission or quality of service out of the box), it does have a rich set of extensions available to allow you to extend its functionality and use it inside different frameworks, and a well-established community to get support from.

In addition, XMPP is better tailored towards chat applications by default, which is not surprising considering its roots in Jabber, and it also comes with multiple layers of security by default. This means less to do yourself in terms of implementing features like client identity and authentication, or presence. It is also arguably somewhat more flexible due to its decentralized architecture, meaning that it is easier to spin up new servers and share admin responsibilities.

WebSockets is newer, but it is still pretty mature, with good browser and platform support. While it is more general and less extensible in approach and comes with fewer features out of the box, it still has extensibility available, and a strong set of available libraries for facilitating chat features (Socket.IO, for example).

Where WebSockets really outshines XMPP is speed and performance. It is faster at transmitting a high volume of data with persistent connections and doesn’t have the same limitations on concurrent connections.  For example, if your use case involves a lot of binary data transmission and multiple connections from each client per server, then it is a better choice.

Your mileage will vary, but to provide a general summary:

• Choose XMPP for extensibility, flexibility, and security.

• Choose WebSockets for speed, performance, high concurrency, and data integrity (ordering and guaranteed delivery).

There are a number of other instant messaging and chat protocols available if you need alternatives:

• Internet Relay Chat (IRC): Another very old-school protocol, IRC has been used to implement instant messaging systems on computers since the late 80s. Better suited to multi-user messaging than SMS, it uses a client-server model, and supports chat rooms, private messaging, and other features such as file sharing.

• Message Queuing Telemetry Transport (MQTT): A very lightweight messaging protocol designed for machine-to-machine communication, MQTT is a good choice for networks with poor conditions and constrained devices, with limited CPU and battery capacity.

• Rich Communication Services (RCS): Designed by Google as a replacement for SMS, RCS features noticeable upgrades such as multimedia support and group chats. It hasn’t been widely adopted; the highest-profile app that uses it is the default Android Messages app.

• WebTransport: A web API designed as an update to WebSockets, which fixes some of its shortcomings and allows reliable and unreliable bidirectional communication with an HTTP/3 server (again using UDP under the hood). WebTransport is very nascent and doesn’t yet have wide adoption, but it is likely to be a good option for chat apps in the future.

We’d also like to mention the option of using a fully-managed, cloud-native solution like Ably to get moving really quickly with your app development. Ably has robust pub/sub messaging, over 25 SDKs targeting every major language and development platform, and dedicated expert support available. With support for multiple protocols (including WebSockets), you can integrate with ease.

Give Ably a try — sign up for a free account and begin exploring by working through our Quickstart guide. Also, read our Chat apps reference guide to find out what we’ve got available to support chat apps.