# IMGo: a Tauri desktop and browser batch image compressor

> IMGo is the Tauri rewrite of meowtec/Imagine, shipping native apps for macOS, Windows and Linux plus a browser version that runs locally. It is a batch compressor and format converter, not a general image editor, and the current builds are unsigned release candidates.

**meowtec/imgo** — 🖼️ Image optimization app for macOS, Windows and Linux.

- Repository: https://github.com/meowtec/imgo
- Website: https://imgo.app/
- Stars: 4,429 · Forks: 319
- Language: TypeScript
- License: not declared
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/meowtec-imgo

## What IMGo is for, and who should care

IMGo is a private batch image compression and conversion tool. The problem it targets is narrow and common: you have a folder of PNGs, JPEGs or screenshots, you want them smaller or in a different format, and you do not want to hand them to a web service. The README states that images stay on your device, and that processing happens locally. That is the whole pitch, and it is a reasonable one for anyone handling client assets, internal screenshots or photos they would rather not upload.

The audience is designers, front-end developers and anyone who routinely ships images into a repository or a CMS. It is not a photo editor. There are no layers, no curves, no selection tools. The README lists quality, lossless, resize and metadata controls, which is the extent of the editing surface.

The project is a rewrite of meowtec/Imagine. The README says it replaces Electron with Tauri for a smaller desktop app, supports more image formats, and adds a full web version. The README also points readers who prefer the original UI but need more formats at Imagine-plus, a separate project by a different author.

## How the Tauri app and the browser version share one codebase

The repository is a pnpm workspace and a Cargo workspace side by side. The JavaScript side holds app/ and website/, and the Rust side lists members including app/src-tauri, crates/minifier, crates/minifier-js, crates/minifier-cli, crates/shared and crates/shared-js. The build script in package.json ties them together: it builds the shared-js crate with wasm-pack, then builds @imgo/minifier-js, then its WASM target, then the web app.

That layout explains the two deployment targets. The browser version runs the minifier compiled to WebAssembly, which is why the README can claim the web app processes images locally without an upload step. The desktop version runs the same Rust crates natively inside Tauri, and the Cargo.toml release profile sets strip, opt-level 3, lto and codegen-units 1, with the two WASM-facing crates compiled for size instead of speed.

Format support differs between the two. The README's table gives the web app JPEG, PNG, GIF, WebP, AVIF and HEIC, while the desktop app adds JPEG XL. Animated PNG, GIF, WebP and AVIF output is supported. If JPEG XL matters to you, that alone decides which build to use.

The dependency tree is not trivial. Cargo.toml patches libheif-sys and jpegxl-src to local paths under deps/, and package.json has an init:src script that resets and reapplies patches against libheif-sys, libde265, libheif and jpegxl-rs. Building from source therefore means initialising submodules and applying patch sets before anything compiles. That is a real cost for contributors, and it is worth knowing before you clone.

## Installing IMGo and compressing your first batch

For most users the README's advice is to skip the build entirely. Open imgo.app in a browser and start processing, or download the desktop build from GitHub Releases. The release table lists a DMG for Apple Silicon or Intel, a Windows installer for ARM64 or x64, and a Linux AppImage for ARM64 or x64. Pick the file matching your OS and processor, then open it.

The README warns that the current Windows installer is unsigned and the macOS app is not notarized, so your operating system may show a security warning the first time you open it. That is expected, not a sign of a corrupt download.

If macOS refuses to open the app, the README gives this exact remedy: move IMGo.app to the Applications folder, open Terminal and run the command below, then open IMGo again.

```bash
xattr -cr "/Applications/IMGo.app"
```

That clears the extended attributes macOS uses to mark the bundle as quarantined. The README does not document an equivalent step for Windows or Linux.

Once the app is open, the workflow is batch-oriented. Drag a set of images in, adjust quality, toggle lossless, set a resize target and decide what happens to metadata, then convert to one of the output formats in the README's table. The README shows a batch processing view and a comparison view in docs/images, so the intended loop is: process, compare against the original, adjust, export.

Building from source is a different proposition. package.json pins Node ^24.18.0 and pnpm ^12, and the init script chains submodule initialisation, patch application, a wasm-pack build, pnpm install, and two minifier-js builds.

```bash
pnpm run init
```

Expect that to take a while and to need a Rust toolchain plus wasm-pack. The README does not walk through this path, so treat the script as the source of truth.

## Where IMGo is the wrong tool

The most obvious limitation is that IMGo is a GUI application. There is a crates/minifier-cli member in the Cargo workspace, which suggests a command line surface exists somewhere in the tree, but the README does not document it. If your build pipeline needs to compress images on every commit or in CI, you cannot plan around an undocumented binary. Reach for an established CLI compressor instead.

Signing is the second constraint, and it is stated plainly. Unsigned Windows installers and a non-notarized macOS bundle mean users see security warnings, and in managed corporate environments those warnings are often policy failures rather than something a user can click past. If you distribute software internally, IMGo's current builds will be awkward to roll out.

The release history is also worth reading literally. The three most recent releases are v1.0.0-rc.1, v1.0.0-rc.2 and v1.0.0-rc.3, all release candidates. Nothing in the README or the release notes says the interface, the defaults or the output formats are frozen. Anyone adopting IMGo for a repeatable process should expect the settings to move.

Finally, no licence is stated for the repository. Neither README.md, package.json nor Cargo.toml names one. Until you confirm it, you cannot reason about redistribution or about bundling IMGo into a commercial product.

## IMGo compared with a scripted compressor such as sharp

The natural alternative for a developer is a library or CLI compressor driven from a build script, for example sharp in Node. The difference is not quality of output, it is where the decision lives. With sharp you write the pipeline: which formats, what quality, what resize rules, and the same rules run on every image forever. With IMGo a person looks at the batch, compares results in the app's comparison view, and adjusts per run.

That makes IMGo better for one-off or judgement-heavy work, such as preparing a set of marketing images where you want to eyeball the result before committing. It makes it worse for anything you need to reproduce. A script can be reviewed in a diff; a session in a desktop app cannot.

IMGo does have one advantage a scripted pipeline usually lacks: the browser version. If you need to compress images on a machine where you cannot install anything, imgo.app runs in the browser and, per the README, processes locally. That is a genuinely different capability, not a restatement of the same feature.

There is also Imagine-plus, which the README names for people who prefer the original Imagine UI but need more formats. If you used Imagine before the rewrite, that is the migration path the project itself points to.

## Maintenance, build cost and licence questions

The repository is not archived and the last push was on 2026-09-19, the same day as the v1.0.0-rc.3 release. Activity is recent, but the project has not cut a stable 1.0.0, so the honest description is a release candidate line that is still moving.

The upgrade cost sits mostly on the build side rather than the user side. Desktop users replace an AppImage, a DMG or an installer. Contributors inherit a heavier chain: pnpm run init resets submodules and reapplies patches to libheif-sys, libde265, libheif and jpegxl-rs, and there is a create-patches script for regenerating those patch files when a dependency moves. Patch files drift when upstream changes, and that maintenance is invisible to anyone using the shipped binaries.

On licensing, the repository does not identify a licence. That is not a detail you can defer. Without a stated licence you cannot assume the right to redistribute modified builds, bundle the app, or ship it inside a product. Check the repository's licence file directly, and if none exists, ask the maintainer before building anything on top of it. This is a factual gap, not legal advice.

## Conclusion

Adopt IMGo if you want batch compression and format conversion that never uploads your files, on a desktop or in a browser, and you can accept a release candidate. Skip it if you need signed, notarized installers or a scriptable headless pipeline; the GUI is the product and the Windows installer is unsigned while the macOS app is not notarized. Before adopting, verify the licence terms, since none is stated in the repository files, and check the release notes for the v1.0.0-rc.3 build rather than assuming the interface is frozen.

## FAQ

### Does IMGo upload my images to a server?

No. The README states that processing is local and that images stay on your device, and it describes the web version as running directly in your browser without an upload step.

### Which output formats does IMGo support?

The README's table gives the web app JPEG, PNG, GIF, WebP, AVIF and HEIC, and the desktop app those six plus JPEG XL. Animated PNG, GIF, WebP and AVIF output is supported.

### Why does macOS refuse to open IMGo?

The README says the macOS app is not notarized, so the system may show a security warning. It advises moving IMGo.app to the Applications folder and running xattr -cr "/Applications/IMGo.app" in Terminal, then opening the app again.

### Is IMGo the same as Imagine?

IMGo is described in the README as the next-generation rewrite of meowtec/Imagine, replacing Electron with Tauri. The README points users who prefer the original UI but need more formats at Imagine-plus.

### Is IMGo a stable release?

The most recent releases listed are v1.0.0-rc.1, v1.0.0-rc.2 and v1.0.0-rc.3, so the current line is a release candidate rather than a stable 1.0.0.

### What licence does IMGo use?

The repository does not state a licence, so the terms are unconfirmed and you should check the repository directly before redistributing or bundling it.

## Sources

- [Issues](https://github.com/meowtec/imgo/issues)
- [meowtec/imgo on GitHub](https://github.com/meowtec/imgo)
- [Project website](https://imgo.app/)
- [README](https://github.com/meowtec/imgo/blob/main/README.md)
- [Releases](https://github.com/meowtec/imgo/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/meowtec-imgo