We've used several broadcasting patterns already across earlier posts. This post pulls everything together into one clear reference, and adds a few useful patterns we haven't covered yet.
The Complete Emit Cheatsheet
Here is every major way to send an event, all in one place:
io.on("connection", (socket) => { // to this one client only socket.emit("event", data);
// to everyone except this client socket.broadcast.emit("event", data);
// to everyone, including this client io.emit("event", data);
// to everyone in room1, except this client socket.to("room1").emit("event", data);
// to everyone in room1, including this client io.to("room1").emit("event", data);
// to everyone in room1 or room2, except this client socket.to(["room1", "room2"]).emit("event", data);
// to everyone, except those in room1 io.except("room1").emit("event", data);
// to a specific client by socket id (private message) io.to(socketId).emit("event", data); });
to() and in() are exact aliases of each other, they behave identically. Most codebases just pick one and stick with it for consistency, to() tends to read more naturally.
A Warning Worth Remembering
You might expect socket.to(socket.id).emit(...) to work as a private message to yourself, but it does not. Every socket automatically has a room named after its own socket.id, and socket.to(...) explicitly excludes the sender. So socket.to(socket.id) targets that room while excluding the one socket in it, meaning nobody receives it. For sending an event only to yourself, always use plain socket.emit(...) instead.
Excluding a Room With .except()
Sometimes you want to reach almost everyone, except one specific group. .except() handles this cleanly:
io.except("banned-users").emit("announcement", data);
You can also chain multiple .except() calls, or pass an array of rooms to exclude several at once:
io.to(["room1", "room2"]).except("room3").emit("event", data);
Private Messaging Between Two Specific Clients
Combining what we know about rooms and socket IDs, a private one-to-one message between two connected users looks like this:
socket.on("privateMessage", (targetSocketId: string, message: string) => { socket.to(targetSocketId).emit("privateMessage", { from: socket.id, message, }); });
Since every socket has its own default room named after its ID, targeting targetSocketId here works exactly the same way as targeting any other room, it just happens to contain exactly one client.
Broadcasting Across Multiple Devices of the Same User
If the same user has your app open in two tabs, or on both their phone and laptop, they will have two separate socket connections, each with a different socket.id. If you want an event to reach every device belonging to one user, you need a way to group those specific sockets together, typically done by having each socket join a room named after the user's actual user ID (not the socket ID) upon connecting:
socket.on("authenticate", (userId: string) => { socket.join(`user:${userId}`); });
io.to(`user:${userId}`).emit("notification", data);
Now, regardless of how many tabs or devices that user has open, all of them receive the notification, since they all joined the same user:<id> room.
The compress Flag
By default, Socket.IO compresses data before sending it. For very small, frequent payloads, this compression overhead can occasionally cost more than it saves. You can disable it per emit if needed:
socket.compress(false).emit("event", data);
This is a minor optimization, and rarely something you need to think about early on, but it's useful to know it exists.
The local Flag: A Multi-Server Consideration
Once your app scales to multiple server instances (which we'll cover properly in Phase 6, using the Redis Adapter), broadcasting normally reaches clients connected to any server in the cluster. If you specifically only want to reach clients connected to the current server process, you can use .local:
io.local.emit("event", data);
For a single-server setup, which is what we are running throughout this course, .local behaves identically to a normal broadcast, since there is only one server anyway.
A Performance Tip Worth Following
One subtle but important best practice: avoid doing async work directly inside a broadcast call, since it delays the entire operation unnecessarily:
// Avoid this io.to("room2").emit("details", await fetchDetails());
// Prefer this instead const details = await fetchDetails(); io.to("room2").emit("details", details);
Resolving your data first, then emitting, keeps the broadcast itself fast and synchronous, rather than blocking on an async call in the middle of it.
Applying This to Our Chat App
Looking back at our chat app from Topic 13, we used io.emit("newMessage", data), sending to everyone including the sender, to keep the server as a single source of truth. Now you can see exactly why that specific choice was made, and how it fits into this bigger picture of broadcasting options. As your app grows, for example, adding private messages or per-user notifications, you now have the full set of tools to choose the correct emit pattern for each situation.
Summary
socket.emit,socket.broadcast.emit,io.emit,socket.to(room), andio.to(room)cover the majority of real-world broadcasting needs.except(room)excludes specific rooms from a broadcast, and can be chained or passed an arraysocket.to(socket.id)does not send to yourself, use plainsocket.emit()for that- Grouping a user's multiple devices into a shared room (e.g.
user:<id>) lets you broadcast to all their sessions at once .compress(false)and.localare minor, situational tools, useful to know about but rarely needed early on- Resolve async data before emitting, rather than awaiting inside the emit call itself
This completes Phase 4. In the next post, we begin Phase 5 by handling reconnection, offline users, and connection state recovery, the first step toward making our app production-ready.