PicSharp: a Tauri desktop compressor that mixes local encoding with the TinyPNG API

Two compression paths, one desktop window

PicSharp is a desktop image compression application, and its central design decision is that compression can happen in two very different places. The first path is local: the file is processed on the machine, with no account and no network call. The second path goes through the TinyPNG API, which means an API key, an upload of the image to a third party, and a service that can reject the request. The README's feature list names both in the same entry, and the configuration table makes the priority explicit: the default uses TinyPNG, and if the TinyPNG compression fails, the app switches to local compression for a retry.

That fallback is the interesting part, and it is also the part a reader should understand before trusting a result. A file can be compressed by a remote service, fail there, and end up compressed locally instead, which means two different codecs produced it. Local compression supports lossless and lossy modes and five selectable levels, so the fallback result is not necessarily visually identical to the TinyPNG result. Anyone using PicSharp on assets where the exact output bytes matter has to know which path ran.

The audience is a desktop user rather than a server operator. The supported platforms are macOS 12 or newer, Windows 10 or newer on x64, and Linux on Ubuntu 20.04 or newer or other distributions.

A Tauri shell over a pnpm monorepo with a Rust sidecar

The repository is a monorepo. The root `package.json` is named `@picsharp/monorepo`, marked private, and versioned at 2.2.7. It declares Node 20 or newer and pnpm 9 or newer as engine requirements, and it ships both a `pnpm-lock.yaml` and a `pnpm-workspace.yaml` alongside a `package-lock.json`, which is a sign of a mixed history in the tooling. A `Cargo.toml` sits at the root with a workspace whose only member is `apps/picsharp-app/src-tauri`, so the Rust side is the Tauri application itself. The Rust toolchain floor is stated in the workspace package as `rust-version = "1.82.0"` with edition 2021.

The top level also holds `apps/`, `packages/`, `doc/`, a `CONTRIBUTING.md`, a `.changeset/` directory, and a `.prettierrc.json`. The presence of `.changeset/` means releases are versioned through changesets, which matches the release tags: v2.2.5, v2.2.6 and v2.2.7 all landed within a week of each other in September 2025.

What the layout does not show is a library package intended for other developers to import. The `packages/` directory exists, but the README describes an application, not a component you embed. There is no documented API for calling PicSharp from a script, which is the main thing that separates this from a command line image optimiser.

Running the app from source with pnpm

The README does not document a build or install command for end users. It points to the GitHub releases page with platform badges for macOS, Windows and Linux, so the supported way to obtain PicSharp is a prebuilt binary from the releases. For development, the root `package.json` provides three scripts that show the shape of the system.

The first starts the Tauri desktop application in development mode:

pnpm --filter @picsharp/picsharp-app tauri dev

The other two run the sidecar package in different modes. One enables the sidecar with clustering turned off:

PICSHARP_SIDECAR_ENABLE=true PICSHARP_SIDECAR_CLUSTER=false pnpm --filter @picsharp/picsharp-sidecar dev

The other selects a command line mode for the sidecar:

PICSHARP_SIDECAR_MODE=cli pnpm --filter @picsharp/picsharp-sidecar dev

These three names are worth reading carefully. The presence of a `PICSHARP_SIDECAR_MODE=cli` switch and a `PICSHARP_SIDECAR_CLUSTER` flag tells you the compression engine is a separate process from the window, which can be clustered across cores. It also means a mode exists where the sidecar runs without the user interface, though the README does not document how to invoke that mode as a finished tool, and no binary name, argument list, or output format is given for it.

Compression mode, level, and the rate limit that discards small savings

The compression settings are where most of the real behaviour lives, and several of them have a slightly surprising effect. There is a compression type toggle, lossless or lossy, and the app switches to lossy when the image does not support lossless compression, so you can lose quality without explicitly asking for it in that case. There are five compression levels for the lossy path.

The setting called compression rate limit is the one to understand first. The README describes it as: when the image compression rate is below the set threshold, saving will not be performed. The practical effect is that a file which is already well compressed is not written back to disk. For a batch workflow this is a sensible guard against a long tail of pointless rewrites, but it also means the output folder will not contain one output file per input file, and a script that expects a one to one mapping will misbehave.

Save type controls how compressed images are written afterwards. Separately, format conversion runs after compression finishes and can produce PNG, JPG, WebP or AVIF. The order matters: the file is compressed first and converted second, so a conversion step can undo some of the size reduction, or introduce artefacts, on a file that was just carefully compressed. The alpha background fill setting exists for exactly that case, letting you choose a fill colour when a transparent image is converted to a format that has no alpha channel, with the README naming WebP, AVIF and PNG to JPG as examples.

TinyPNG API keys, metadata preservation, and what leaves your machine

The TinyPNG section of the configuration manages multiple API keys, with availability detection and usage monitoring, so you can rotate keys and see which one is working. Metadata preservation is a separate switch, letting you select which metadata survives compression. Metadata handling matters more than it sounds: a PNG that keeps its embedded metadata can carry text chunks, timestamps, or colour profiles that defeat some of the size saving, and the same applies to EXIF in photographs.

The privacy question is the deciding factor for many teams. When the compression mode is TinyPNG, the image is uploaded to a hosted service. The local path never leaves the machine. Because the default mode is TinyPNG, a user who never opens the settings is uploading by default, which is a behaviour that deserves a line in any internal tool approval. The README does not document any retry count, request size limit, or what happens to an image when the API rejects it beyond the fallback to local compression.

A second thought applies to a desktop tool with no project homepage of its own. The GitHub repository is the listed homepage in the package manifest, and the releases page is the distribution point. There is no separate site, and the README does not point to one.

Batch, watch mode, clipboard, and a macOS-only Finder path

The everyday features are the ones the README shows as screenshots: batch processing, watch mode, and a rich configuration set. Watch mode means the tool keeps running and picks up changes, which is the mode that turns a one-off compressor into part of an asset pipeline for someone who edits images in a directory.

Clipboard support lets you compress images or directories taken from the clipboard, and the Finder Services entry adds a compress action in the macOS Finder context menu. The Finder Services row is explicitly marked as Mac only, so the feature set is not identical across the three platforms even though the core compression is. Internationalization is described as partial, with zh-CN and en-US listed, and there is a dark and light theme, system notifications, an option to start on boot, and an automatic update check.

The tradeoff in this design is that the same behaviours are exposed differently on each operating system, and there is no single command surface to script against. If your workflow is to put files in a folder and get smaller files out, the watch mode covers it. If your workflow is a nightly job in CI, the README does not offer the entry point you would need.

AGPL-3.0 across both the npm package and the Rust crate

The licence is AGPL-3.0, and it is declared in two places. The root `package.json` sets `"license": "AGPL-3.0"`, and the `Cargo.toml` workspace package sets `license = "AGPL-3.0"` as well. The repository root contains a `LICENSE` file. Both manifests agreeing on the same copyleft licence means the terms are intended to cover the whole codebase rather than only the application shell.

What that means for an end user is simple. Installing the binary and using it on your own images is not a distribution event in the way a modified service is, so the obligations bite in other situations: if you fork the code, if you modify it and let others run it over a network, or if you redistribute a build. This is a licensing question to check against your own use, not a conclusion to draw from a one line manifest field, and the `LICENSE` file itself is the only authority. The `CONTRIBUTING.md` file and the `.changeset/` workflow suggest the project expects outside contributions, which is worth noting when you plan to send patches.

On maintenance, the last push to the repository was on 2026-04-13, and the most recent tagged release is v2.2.7 dated 2025-09-30, with v2.2.6 and v2.2.5 a few days earlier. Between the newest release and the last push there is a gap of months with no tag, so the project should not be described as actively maintained, and the release history is thinner than the desktop app market moves.

Editorial conclusion

PicSharp suits a desktop user who compresses images in batches, wants a watch mode, and prefers a local tool to uploading assets to a hosted service, and it suits maintainers who want to wrap the TinyPNG API in a native shell. It does not suit a server-side pipeline that needs a documented command line interface, since the README documents only the graphical application and the monorepo development scripts, and it does not suit a project that cannot accept AGPL-3.0 obligations. Before you rely on it, check the release page for a build matching your platform floor (macOS 12+, Windows 10 x64, Ubuntu 20.04 or later) and read the AGPL-3.0 file in the repository root to see whether your distribution model is compatible with it.

Frequently asked questions

Official sources

1. AkiraBit/PicSharp on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases