On February 4, 2025, I published Emojam and Emoji Story-Telling Memories. The article was prompted by the Emojam, a Japanese “pager” for kids which only allows for messages made up up of pre-loaded emoji (see Emojam report). I only spent a few sentences on the Emojam itself before segueing into a story from my high school days where my friend made up a plot from the “24” TV show by employing emojis accompanied by dialogue as an example of the untapped power of emoji-based story-telling. I thought of my Emojam-inspired anecdote when I read Max Gelnister’s January 12, 2026 article titled Building an emoji-only chat app.

Max Genister explained that his six-year old daughter enjoys sending and receiving emojis. He wanted to allow her to send him and receive emojis, but also wanted to separate the emojis from his main chat app. While there were apparently existing emoji-only chat options on iOS, they had two issues. Firstly, Mr. Glenister was not comfortable with the lack of information about how they handled data. Second, they only allowed 1:1 chats.

While I would have been stumped at this point, Mr. Glenister is a web developer. Over the course of a weekend, he built a new web-app called Moji. He describes the concept as follows:

Emoji only – the app only allows non-alphanumeric characters. Random room IDs get generated when starting a chat, but any string works. No accounts means nothing to store, nothing to manage. Type a name when joining and that’s it.

He also explained how he worked to avoid storing data on a central server:

I used GunDB for peer-to-peer messaging so messages stay between whoever’s in the room, not on my server or in the cloud. The frontend is React, using Vite and Tailwind. The relay server is just Express with GunDB, about 15 lines – it only helps peers find each other.

The source code for Moji is available on GitHub. But as of the date of the publication of this article, one need not deploy his or her own Moji instance to try the app. Mr. Glenister deployed Moji using the Fly.io service and the instance is live at https://moji-frontend.fly.dev/ as of the initial publication date of this article (it can also be installed on supported devices as a progressive web app).

I decided to call upon our fictional dialogue duo, Justin and Justina, to test out the app.

First, Justin chooses a color and user-name and then creates a room.

Login screen for Moji web app. Fields for choosing username, color, and starting a room. Background outside of the menu window is bright yellow.
You can use the room link or ID to join an existing room.

The room is empty. Justin clicks the field to send messages and sees that he can only send emojis.

Chat window and emoji keyboard showing nothing but emojis in Moji chat app. Dialogue window is empty.
Emoji keyboard in Moji chat app.

He decides to invite a friend. There is no “invite” button, but from reading Mr. Glenister’s article he understands that the URL is the link to the room. He cryptically sends the link to Justina. Justina, feeling suspicion, opens the link. Note that when she opens the link, she sees a different welcome screen than Justin saw when he opened the room.

Moji log-in screen with red background in Brave. Fields for creating username and color. This was opened pursuant to an invite so only option is to join room.
Joining a room in Moji.

She has name and color options, but there is only a single button to “Join Room” instead of an additional option to “Create Room.”

Justin and Justina proceed to begin a conversation. First, see the conversation from Justin’s side using the Mullvad web browser, which is derivative of Firefox.

Emoji conversation in Moji chat app seen in Mullvad web browser.
Moji in Mullvad.

Now see the conversation from Justina’s side using Brave, which is derivative of Chromium.

Emoji conversation in Moji chat app seen in Brave web browser.
Moji in Brave.

Note that the emojis look different. Mr. Glenister noted this issue:

Emoji render differently across devices. The picker shows one set of glyphs, but messages display in whatever the system provides. I tried using Twemoji to keep things consistent but gave up – too much overhead. Works fine for now.

I also discussed the potential problem of emojis displaying differently on different devices in a 2022 essay titled Emojis, Corporations, and Censorship. With that being said, I doubt that the sorts of entirely emoji-based conversations on an app like Moji will be adversely affected by differing emoji appearances.

Moji conversations use the web browser’s local storage. Brave keeps local storage by default, so Justina could close out of her conversation and most likely access it again in the future. However, Justin’s browser Mullvad clears itself on close (by design), so he would lose access to his conversations upon closing. But before Justin closes, see below what the Moji homepage looks like in his browser with the existing chat still in local storage.

Signing into Moji chat app with one room already open and available to re-join.
See Justin’s existing room in browser cache at the bottom.

Justin now has a third option in addition to “Create New Room” or join a room using its ID. He can now re-join the room he created to exchange emojis with Justina. While testing, I discovered that if you change your user-name and then return to a chat, the chat treats you as a new participant. For example, if Justin changed his name to Justinian and then returned to the room he created, “Justinian” would be treated as a new participant in the chat. However, were Justin to then join from an entirely different web browser and set his username as “Justin” with the same color as when he first made the room, Moji would treat him as the original “Justin” despite the fact that he is using a new web browser.

Moji looks good and works well in my brief testing with a friend and with “Justin and Justina.” I rate this as an impressive weekend project. While I assume that it is largely “feature complete” from Mr. Glenister’s perspective since he notes he created it for his daughter to enjoy and wrote it up to explain the tech behind it, I humbly offer a few suggestions were he or someone else to want to consider improvements for broader use while keeping to the simple spirit of the concept. I will set aside standardizing the appearance of emojis across devices and web browsers since he already noted that issue in his blog post.

Firstly, while I would not disturb the emoji-only messaging concept, I would like the ability to use text search for emojis. See, for example, how I can search for emojis in my favorite traditional messaging app, Delta Chat:

Running text search for "bird" in emoji select window in Delta Chat.
Searching for emoji in Delta Chat.

I do not use emojis so frequently that I am able to find specific ones quickly, and even if I were an emoji story-teller, I think I would find having to scroll-to-search cumbersome.

Secondly, I think text tooltips when hovering over an emoji would be a nice addition. See below what happens when I hover over the hatching chick emoji in Delta Chat:

Hovering over "Hatching Chick" emoji in Delta Chat with tooltip "Hatching Chick."
Note I can see the text describing the emoji when I hover.

Contrast with Moji:

Hovering over hatching chick emoji in Moji chat app. There is no tooltip.
Find my cursor hovering over the hatching chick in the second row of emojis, ninth from the right.

Tooltips would provide two benefits. Firstly, some people who try the app may not be familiar with all of the common emojis. While the hatching chick is self-evident, I find some of the smilies ambiguous. Secondly, so long as the appearances of emojis in Moji varies depending on the chatter’s device and web browser, tooltips would help ensure that chatters are able to send the emoji they intend to send.

Thirdly, rooms should have an “invite to room” button that brings up the sharing link. This would make sharing rooms more intuitive for people who are not technically inclined or who are linked to Moji without having read the introductory blog post.

Fourthly, it may be worth considering how Moji handles “usernames.” It seems a little bit unintuitive to treat someone who accesses a chat from the same browser but then changes his or her username as a new user. Similarly, while there is a benefit to treating someone who accesses from a new browser as a returning user if he or she chooses the same username and color that he or she used on a different browser, this could also lead to false impersonation. While Moji is somewhat abuse-proof in that rooms require specific URLs/room codes and the only things that can be sent are emojis, it may be worth revising how user “accounts” are handled (alas, this is a case where I can more easily identify the issues than offer solutions).

Fifthly, Moji could be enhanced with chat export functionality. I would be most interested in having the ability to export Moji “conversations” for future reading, perhaps into HTML or a similar format. With that functionality, people could save and post Moji “conversations” (for example, I could use Moji to put together an entire Justin and Justina dialogue).

Finally, it would be a nice (albeit unnecessary addition) to include a color picker, which would allow people to choose their own chat colors. I describe this suggestion as “unnecessary” because Moji already has 16 default color options, but some Moji chatters may appreciate being able to define their own chat color.

Moji is a fun app and looks slick for a weekend project. I see how it could be fun for kids and emoji story-tellers alike. I hope that Mr. Glenister continues to maintain the public instance and considers making some tweaks to improve it further. Consider this review my small contribution to the project.