FaceMoji: covering detected faces with emoji, offline, on Android and the web

A redaction tool with a playful default, not a security product

FaceMoji reads an image that you pick inside the app or that another app shares to it, detects the faces in it, and covers them with emoji expressions. The description of the repository is blunter than the app name: identify faces in an image and replace them with emojis. That framing sets the expectation correctly. This is a privacy utility with a playful default rather than a security control, and the project says so in its own notes, where it states that the app is provided as is with no warranty of any form. It also states that the face recognition model it uses has performance limits and that in some cases there may be misdetections or missed detections. That is the single most important fact for anyone evaluating it. A tool that covers most faces in a fun photo is a different proposition from one that reliably anonymises a face, and the project does not claim the second.

The face detector is YOLOv8, borrowed from another project

The acknowledgements section names the model explicitly: the project uses the pretrained model provided by derronqi/yolov8-face for face detection. That is a general object detection network trained for faces, not a purpose-built face recognition system, and there is no sign in the repository of a custom training pipeline for this use case. The credits also list the application icons as coming from the Carnival Masks Pack by freepik, modified for the project. What the acknowledgements do not include is any statement about how the model was evaluated, on what data, or at what detection rate, so there is no accuracy figure to reason from. The practical implication is that the quality of the result depends on the incoming photo. Small faces, faces at a steep angle and heavily compressed images are the cases where a general detector tends to struggle, and the user is left to check the result visually before sharing.

Emoji is the default, blur is the setting, and both are editable

The feature list describes more than a one-shot filter. The application automatically recognises faces in a picture and applies a preset effect, and the default effect is to cover a face with an emoji expression, while a blur effect can be selected in settings. You can then add, modify and delete emoji or blur regions on the image yourself, so the automatic pass is a starting point rather than the final answer. The available blur effects include Gaussian blur, pixelation and a halftone dot effect, and the project is upfront that the halftone differs somewhat from the standard definition. There is also a custom emoji font import, which lets you bring your own font file so the cover uses the emoji set you actually have installed, rather than whatever the system provides. That combination of automatic detection plus manual correction is what makes the tool usable, because it means a missed face is something you can fix by hand rather than a failure of the whole run.

Two APK flavours exist because the icon can be hidden

One of the listed features is hiding the application icon, and in that state the app can only be started by sharing an image to it from another application. The project offers two APK versions to suit different habits. The default variant shows the app icon after installation, and the icon can be hidden later in settings, though the documentation notes that this may not work perfectly on some Android systems. The icon-disabled variant hides the app icon from the start, and it is the recommended one if you mainly intend to use the app through the share function of other apps; the icon can still be unhidden from the app settings. The rationale is straightforward once stated. A face-blurring tool has no business sitting on your home screen, and the launcher icon is a small but real disclosure of interest, so the share-only distribution model is the one that makes sense for this category of app. The Android build is a Gradle project with an app module, build.gradle.kts and settings.gradle.kts, written in Kotlin, and the default branch is dev.

The web build is a generated deployment, not a maintained product

There is a web version that needs no installation, works immediately, supports PWA installation, and does all processing locally, which the documentation presents as privacy friendly. It is deployed with the Vercel button in the README, and the deployment notes say that a manual deployment must set the Root Directory to web, with the web version's own documentation in web/README.md. The honest context for all of this is in the project notes, which state that the web version was entirely generated by Jules, described as a vibe coding tool, that it is usable overall, and that code quality and stability are not guaranteed. That is a substantially different assurance level from the Android application, and it is stated plainly rather than hidden. The web directory sits alongside the Kotlin app in the same repository, so the two implementations are versioned together even though they share no code, and the release tags, named for their date, cover both.

Everything runs on the device

The third note in the project documentation states that all processing is done offline. That applies to both the Android app and the web version, and the web deployment to Vercel serves the application while the processing stays in the browser. This is the strongest genuine claim the project makes, and it follows from the architecture rather than from a policy. The model runs on the device, the image never leaves it, and the web version is a static deployment with no server-side image handling. For a tool whose entire purpose is touching photographs of people, on-device processing is the property that makes it usable at all, and it is also the property that makes the deployment of the web version a non-issue from a privacy standpoint. What the offline guarantee does not cover is the accuracy of the detection, and the two notes sit next to each other in the documentation for a reason: the processing is local and the results are approximate.

GPL-3.0, a dev branch, and dated release tags

The licence is GPL-3.0, which is the decision to look at most carefully before you build on this. A strong copyleft licence means that distributing a modified version carries source availability obligations, and if you were planning to fold this into a larger application, or to rebrand it, that is a legal question for your own counsel rather than something the repository can answer. The rest of the project metadata is straightforward. The repository is not archived, the last push was on 2026-10-17, and the default branch is dev rather than main, which tells you the published work happens on a development branch. The release tags are dated rather than semantic, with names such as release-2026-10-17-01, release-2026-09-17-01 and release-2026-09-16-02, and the latest one is dated the same day as the last push. So the project is moving, frequently, with a rolling tag scheme that gives you a dated artefact to download but not a version number that means anything semantically.

Editorial conclusion

Adopt FaceMoji if you want a quick, private way to redact faces in a photo before sharing it, and you are happy with a detection model that can miss a face or flag the wrong one, since the project says so itself. Do not adopt it as a redaction tool for anything where a missed face has consequences, such as evidence handling or a compliance workflow, and treat the web build as a demonstration rather than a product, because the project states it was generated by an AI coding tool and that its code quality and stability are not guaranteed. Before you commit, test the detector on the kinds of images you care about, and check the licence obligations of GPL-3.0 against how you intend to distribute the app.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Steve-Mr/EmojiFace on GitHub