Compressor, an Android video compressor built on Media3 instead of FFMpeg

What the app does and the decision behind its size

Compressor is described as a lightning fast, ad free, super lightweight native video compressor for Android, inspired by the Kompresso app for iOS. It is a Kotlin app with a Jetpack Compose interface, published on Google Play and on IzzyOnDroid, with a project site at compressor.joshattic.us.

The architectural decision is the one the README argues hardest for. Compressor uses the native Media3 library rather than another slow, bulky FFMpeg wrapper. That single choice explains most of the rest of the feature list: the app needs no third party libraries, since Media3 is part of the platform, and it avoids the size and speed penalty of shipping a transcoding binary inside the APK.

Using the platform encoder also means the app inherits what the device can do. The README lists H.265 and AV1 support for compatible devices, which is exactly the qualification: AV1 hardware encoding only exists on recent flagship silicon, and on older devices the app falls back to what the codec supports.

The rest of the list is a statement of what the app does not do. No invasive permissions, with no storage and no internet access, which for a video compressor is a genuinely strong claim since a naive implementation would need broad file access and would want to phone home. Ad free, which for an Android utility in 2026 is a differentiator rather than a default. Completely native Kotlin, with no cross-platform wrapper in the middle. Share sheet support, so it appears in the share menu of a gallery or file manager. Works on Android 7.0 and up. And reproducible builds, which lets you verify that the binary you download matches the source.

The MIT licence and the presence of a CODE_OF_CONDUCT.md and PRIVACY.md in the repository are the small signals that this is maintained like an open project rather than a closed app with a source dump.

Reading the benchmark tables honestly

The README publishes four benchmarks and, unusually for an app, explains the methodology rather than just the results.

The test devices are listed with their SoC and RAM: a Pixel 8 Pro with Tensor G3 and 12 GB, a first generation Pixel with Snapdragon 821 and 4 GB, a Galaxy Z Flip6 with Snapdragon 8 Gen 3, a Galaxy S21+ with Exynos 2100, a Galaxy S10 with Exynos 9820, a Galaxy A05s with Snapdragon 680, a ZTE Blade A73 5G with Unisoc T760, an Oppo A5 2020 with Snapdragon 665, and a Nokia 7 plus with Snapdragon 660. That range from a 2022 flagship to a budget device is the point, since the speed of a hardware encoder depends entirely on the silicon.

The methodology notes matter for reading the numbers. In the 1.5.2 benchmarks the devices were kept chilled in a cooler between runs, while for 1.6.3 all tests were run at realistic ambient room temperature of about 21 degrees with no active cooling, to reflect real use. Timing was captured manually with a stopwatch, so a small margin of error is expected. And where the same device was re-tested, the earlier result is shown for comparison.

The first benchmark is 4K 60fps HEVC SDR at 197.3 MB with the Medium preset. The Pixel 8 Pro goes from 13 seconds 42 milliseconds to 10 seconds 55 milliseconds, roughly 21 percent faster. The Galaxy S10 improves from 21 seconds 24 milliseconds to 14 seconds 19 milliseconds, about 33 percent. Three devices were ineligible because the hardware cannot handle the video.

The second benchmark is harder: 4K 30fps HEVC HDR10+ at 136.8 MB. Here the numbers are less uniform. The Pixel 8 Pro improves by about 12 percent and the Galaxy Z Flip6 takes 5 seconds 79 milliseconds. But the Galaxy S21+ goes the other way, from 9 seconds 27 milliseconds to 10 seconds 47 milliseconds, which the table records as a slowdown rather than hiding it.

That is the detail that gives the tables credibility. A benchmark section where every device improved would be a marketing document. One where an Exynos device got 15 percent slower at the same preset is a measurement.

Getting the app and the sibling project

There is no build instructions section in the README, which fits an application distributed through app stores rather than a library.

The distribution channels are the Play Store listing under the package compress.joshattic.us and the IzzyOnDroid repository, which is a FOSS catalogue for Android. The README links both. The IzzyOnDroid route matters for anyone who wants the app without the Play Store, and the badges in the README show version tracking for both channels.

For a developer, the repository is a standard Gradle Android project. The top level has build.gradle.kts and settings.gradle.kts written in the Kotlin DSL, a gradle.properties, the gradlew wrapper script and its Windows variant, an app/ directory, a gradle/ directory for the wrapper configuration, an assets/ directory holding the logo and the screenshots used in the README, a fastlane/ directory for release automation, a crowdin.yml for translations, and a PRIVACY.md and CODE_OF_CONDUCT.md.

The gradle wrapper being checked in means you can build without a local Gradle installation, which is the standard expectation for an Android project now.

The README also points to a second project, Compressor Edge, and recommends it to anyone who wants more advanced features. The wording is that Compressor Edge receives extra features and fixes not found in Compressor. That is the pattern of a maintained open source app that has outgrown its original scope: the simple version stays stable and gets bug fixes, and the new work goes into the more capable sibling. Choosing between them is a question of whether you want a share-sheet tool that does one thing well or a fuller editor.

The funding arrangements are also visible in the README, with a Buy Me a Coffee link and cryptocurrency addresses for Bitcoin, Ethereum, Litecoin and Solana. That is worth knowing if you are evaluating the project as a dependency, since it tells you the maintenance model is donations from users rather than a company behind it.

What the interface and permissions mean in practice

The screenshots in the README show four states, and together they describe the whole flow: a selection screen, a settings screen, a compressing screen and a done screen.

The selection screen is where you pick the clip, and it is also the screen that reveals the permission model. An app that browsed your library directly would need storage access, so instead the app is invoked from the share sheet of a gallery app or file manager, receives the selected item, and hands the result back the same way. That is why the README can claim no storage permission and no internet permission without qualification: the app never asks for broad file access, and it never needs to send anything anywhere.

The settings screen is where the presets live. The benchmark tables name a Medium preset, which implies a small set of named levels rather than a slider with arbitrary bitrate and resolution fields. That is a deliberate simplification. Exposing every encoder parameter would let you pick a combination the hardware encoder cannot do, which on some devices means a much slower path or an outright failure, so a small set of tested presets is the safer design.

The compressing screen shows progress, and the done screen offers the result. From there the share sheet takes over and you can send the compressed file to wherever you want it, which is how the workflow avoids a file manager and a naming convention entirely.

The privacy angle is worth stating plainly for anyone who handles video on a phone. Video clips are sensitive in a way that documents often are not, and an app that needs no internet permission and no storage permission has a very small surface. The PRIVACY.md file in the repository is the place to check the details of what, if anything, is collected, and it exists alongside the code rather than on a marketing page.

The reproducible builds claim belongs in this section too, since it is a supply chain property rather than a feature. When a build can be reproduced, two people building the same commit get the same binary, which means a published APK can be checked against the source rather than taken on trust.

Where it fits against the alternatives

The alternative for most people is a general purpose video editor, and the difference in approach is significant.

An editor such as a full mobile video app gives you trimming, filters, transitions, speed changes and a timeline. Compressor gives you a compression operation: pick a clip, pick a preset, get a smaller file. The README's own screenshot set tells you the shape of the flow, moving from a selection screen through settings and a compressing screen to a done screen.

The second alternative is a desktop tool, which will always be faster because it uses a desktop CPU rather than a phone encoder, at the cost of having to transfer the file. The benchmark tables here are also implicitly an argument about why doing it on the phone matters: the files are already on the phone, and for a clip you just shot, copying it to a computer is the slow part.

The third alternative is doing it in bulk on a server, which is what you would want for a library of footage rather than a single clip. Compressor is not built for that; it compresses one selection and hands you the result through the share sheet.

The honest limitations follow from the design. Media3 exposes what the device's hardware encoder supports, so the achievable quality at a given size is set by the phone, and on an older device with an older encoder you get H.264 and worse ratios. The app is Android only, with a minimum of Android 7.0. And the permission model, while commendably narrow, means it works through the share sheet and the system picker rather than browsing your library directly.

For the specific job of making one video smaller on an Android phone, with no ads and no data collection, the case for this app is simply that it does that job and nothing else.

Editorial conclusion

Adopt Compressor if you compress video on an Android phone regularly and want a small, ad-free app that uses the hardware encoder already on the device. Skip it if you need frame-accurate trimming, filters or a batch pipeline, since this is a share-sheet tool for a single clip, not an editor. Verify first by installing the release build from Google Play or IzzyOnDroid, compressing the same clip twice on the same device, and comparing the timing with the README's figures for that device, since the published numbers depend on the codec the hardware supports.

Frequently asked questions

Official sources

1. JoshAtticus/Compressor on GitHub
2. License: MIT
3. Project website
4. README
5. Releases