AJAX Chat: a forum-embeddable web chat that polls the server for new messages

The update model is polling, and the README is upfront about it

AJAX Chat Standalone is the standalone version of Blueimp's AJAX Chat, and the branch structure matters. The README says that if you are looking for a version to integrate with your forum, you should select a different branch. The mechanism is described plainly. The clients, meaning the user browsers, use JavaScript to query the web server for updates, and instead of delivering a complete HTML page only updated data is sent in XML format. By using JavaScript the chat page can be updated without having to reload the whole page. The performance-oriented option is a Flash based socket connection for pushing updates, which the feature list describes as optional support to push updates over a Flash based socket connection for increased performance and responsiveness. The design is from the XMLHttpRequest era, and it is honest about what it does.

The server stack is PHP and MySQL, and the requirements are old

The Requirements section gives a table that is worth reading carefully, because it dates the project. On the server side it asks for PHP 5 or newer and MySQL 4 or newer, with Ruby 1.8 or newer listed as optional, and the client side asks for enabled JavaScript and enabled cookies, with a Flash plugin version 9 or newer listed as optional. The optional Ruby and Flash entries are there for the socket connection path, and both are technologies that have since been superseded. For anyone evaluating this today, that table is the single most important line in the README. The project itself is described as a fully customizable web chat implemented in JavaScript, PHP and MySQL which integrates nicely with common forum systems like phpBB, MyBB, FluxBB, SMF and vBulletin, and the version and architecture statements in the repository metadata point at PHP 7 as the target.

The feature list is a forum chat, not a team messenger

The features read like a 2010 era forum plugin, and that is exactly what it is. Usable as shoutbox, multiple channels, private messaging, private channels, and an invitation system. Kick/Ban or Ignore offending users. An online users list with a user menu. Emoticons and smilies with an easy way to add custom emoticons, and BBCode support. Then the chat-native behaviours: IRC style commands with an easy interface to add custom commands, flood control, the possibility to delete messages inside the chat, and the possibility to define opening hours for the chat. Guest users can be enabled or disabled, and there is persistent client-side settings. Several items are quality of life for a forum community specifically, such as automatic adjustment of displayed time to local client timezone and the automatic detection of language from the ACCEPT_LANGUAGE browser setting.

Bandwidth is the design constraint behind the XML format

Two features in the list are really the same decision taken twice. Bandwidth saving update calls, where only updated data is sent, and the choice to send XML rather than a whole page. For a chat room on a forum where a hundred people are online and most of them are not talking, the difference between shipping a full HTML page per user per interval and shipping only new lines is the difference between a chat that works on a shared host and one that does not. Related to that, the client survives connection timeouts, and the page can update the window title as an optional visual update information, which is a small touch that tells a user in a browser tab that something happened. The README also notes that long words are split to preserve chat layout, and that any text input is accepted, including code and special characters, which matters for a forum where people paste things.

Security and standards were stated as requirements, not afterthoughts

One feature line is worth pulling out, because for a chat plugin on a community forum it is the line that matters. The project says it was developed with security as an integral part, built to prevent code injections, SQL injections, cross-site scripting, session stealing, and other attacks. Session handling and authentication are the hard part of any chat that shares a forum's user base, and the feature list also claims easy integration into existing authentication systems with sample phpBB3, MyBB, PunBB, SMF, and vBulletin integrations available. Standards compliance is claimed too, with XHTML 1.0 strict. On the client side, the separation of layout and code through stylesheets and templates is what makes the customisation promise real, and the README calls out multiple styles with easy layout customization through stylesheets and templates, plus multiple languages.

There is no install command, and the documentation is scattered

The README does not contain an installation command, and it says where the information lives instead. Essential documentation is contained in the attached readme files, and for more documentation it points at the GitHub wiki. Support questions go to a Google group, and bugs go to GitHub issues. The repository listing is thin in a way that matches that, with a `chat/` directory, a `readme.md`, and a `.gitignore` at the top level, so the readme files referred to in the README live inside the `chat/` tree. If you are evaluating this, expect to spend an afternoon in the wiki and in the per-component readme files rather than in a single setup page, and expect the answer to whether your forum version is supported to be in the branch list rather than in the README.

Where AJAX Chat is the wrong tool

Two limits are decisive, and one of them is time. The release list shows 0.8.8 tagged builds for phpBB3.1, Xenforo, and vBulletin in April 2016, and the last push to the repository was on 2026-07-16, with no GitHub releases beyond those 2016 tags. The code may well have moved on, but there is no versioned artefact to pin, so adopting it means taking the current state of a branch that has not been cut in a decade. The second limit is the transport. Polling with an optional Flash socket is a design for a forum community on shared hosting, and if you need presence, typing indicators, read receipts, or anything resembling a modern messaging experience, you would be building those on top of a request-and-response loop, and the Flash accelerator is no longer an option because the plugin is gone from browsers. For a new project, a websocket-based client or a hosted service is the better starting point, and this project makes more sense as a fork to study than as a dependency to deploy.

Editorial conclusion

AJAX Chat fits a forum community that wants a chat room inside its own pages, on its own server, sharing the forum's user accounts, and that is comfortable with PHP and MySQL hosting. It is the wrong choice for a new product, because the newest tagged releases in the list date from 2016 and the last push was on 2026-07-16, so you are adopting a decade-old codebase. It is also the wrong choice if you need modern realtime behaviour, since the update path is browser polling and the optional accelerator is a Flash socket. Before you deploy it, read the readme files inside the `chat/` directory that the README points to, confirm your forum integration branch matches your forum version, and check the stated requirement of PHP 5 or newer against the PHP 8 your host actually runs.

Frequently asked questions

Official sources

1. Frug/AJAX-Chat on GitHub
2. Issues
3. Project website
4. README
5. Releases