Removerized: background removal and upscaling that runs on WASM in your browser tab

The architecture in one sentence: WASM inference plus IndexedDB

The README has a How It Works section with four bullets, and together they describe the whole system. Models are loaded directly in the browser. Inference runs using WebAssembly. Assets are cached locally via IndexedDB. No data ever leaves your device.

That last bullet is the product. Background removal and upscaling are normally server operations: you upload, a GPU does the work, you download. Removerized inverts that by shipping the model to the client, so the image never has to be transmitted or stored anywhere. The features list repeats the promise in the project's own words, no uploads, no servers, no limits, plus client-side only, zero backend, zero data collection.

The runtime is `onnxruntime-web` at 1.24.3, the WebAssembly build of ONNX Runtime. The models themselves are ONNX format, which is why quantized variants are named in the release notes. Inference in WASM is CPU-bound, and this is the single most important fact about the project: it is fast enough for interactive single images and slow for volume.

The caching layer is where most of the engineering went. Models are stored in IndexedDB so a second visit does not re-download them, and the app is described as offline ready, working without internet after the first load. There is a `config/` directory in the tree, which is presumably where model URLs, names and sizes are declared.

What v1.0 actually shipped

The 1.0.0 release notes are unusually honest about history. They state that from that version forward the changelog begins official tracking, that the project went through multiple stages including early open-source iterations and an experimental SaaS direction, and that 1.0.0 represents the first stable definition of the project as a local-first, open-source AI image toolkit.

That sentence is worth more than the marketing copy. A project that tried a hosted version and came back to local-first has made an architectural decision under pressure, and you can read the consequences in the dependency list.

What 1.0.0 shipped: background removal using multiple AI models through ONNX Runtime Web, image upscaling, a batch processing system, a model selection interface so the user picks the processing model, IndexedDB model caching for offline reuse, fully client-side processing with no backend, and offline support after initial load.

Batch processing and model selection together are the features that make it more than a demo. Choosing between models matters because segmentation quality on hair, fur and semi-transparent edges varies sharply between a small quantized model and a large one, and being able to switch is how you find the right trade for your images rather than accepting whatever the author picked.

v1.1.0 adds colorization and turns it into an installable app

The 1.1.0 release, published 2026-04-12, is a feature release with a long list. Image colorization arrives using DeOldify models. Canvas work follows: custom zoom controls for zoom in, zoom out and reset, a zoom level indicator showing the current percentage, keyboard shortcuts using Ctrl or Cmd plus the mouse wheel, and a floating version button on the canvas that opens a changelog dialog.

The changelog dialog loads a CHANGELOG file dynamically from the public folder using fetch, and includes a link button back to GitHub. That is a small detail with a large consequence for a tool that works offline, because the in-app changelog updates without shipping a new build.

The bigger change is packaging. Progressive Web App support arrives with Serwist and Turbopack, a service worker for offline functionality, a web app manifest with icon configuration, and an install button that appears when the app can be installed. `@serwist/next` at 9.5.7 appears in the dependency list to back it up.

For an offline-capable local tool, PWA support is not a nice-to-have. A browser tab is a poor long-lived container, and being able to install the app gives it a real app window that survives closing the tab. Combined with the service worker, that makes the offline claim from the README much more literal than it would otherwise be.

v1.1.1 is a postmortem of where this design breaks

The 1.1.1 release notes, published 2026-04-15, read like a bug report on the architecture. Three days after a feature release, the fix list is entirely about hangs.

The Upscaler could hang indefinitely during model download when the network stalled. It could remain stuck during ONNX session creation or inference without timing out. The fix adds timeout and abort handling across four separate stages: model download, model stream reads, session initialization, and inference execution.

That list is a map of the failure modes. A multi-hundred-megabyte model download over a stalled connection has no natural deadline in a browser, session creation for a large ONNX graph can take long enough to look frozen, and inference in WASM is synchronous enough from the UI's perspective that a slow computation reads as a hang. Every one of those is a direct consequence of putting a multi-hundred-megabyte model and a CPU-bound runtime in a browser tab.

The release also changes the default remover model to `ormbg_quantized`, moves BiRefNet Lite model URLs to a new `BiRefNet_lite-ONNX` repository from ONNX Community, and renames `birefnet_lite_quantized` to `birefnet_lite` for the FP32 variant with an updated size of 224 MB and a description covering standard precision.

Two things follow from that. The model hosting moved out of the project's own release assets to the ONNX Community repository, which makes the download path depend on a third party. And the FP32 variant is 224 MB, which is why there is a quantized default at all. Expect the first run of this app to be a download, not a page load.

Running it locally takes pnpm and nothing else

The README's Getting Started section is two commands:

pnpm install
pnpm dev

No API keys, no backend to start, no environment file to fill in. The scripts in the package manifest back this up: `dev` maps to `next dev`, `build` to `next build --webpack`, `start` to `next start` and `typecheck` to `tsc --noEmit`. The explicit `--webpack` on the build is notable, since Next.js 16 defaults toward Turbopack and this project pins the older bundler for the production build, presumably for ONNX or WASM handling reasons.

There is also `preview`, which runs the build and then starts it, and a pair of formatting scripts using Prettier over ts, tsx and mdx files.

The stack is Next.js 16.2.3 with React 19.2.4, TypeScript, shadcn/ui built on Radix primitives, Tailwind CSS and lucide-react for icons. The shadcn setup brings the usual component inventory: dialog, dropdown menu, label, progress, scroll area, select, separator, slider, tooltip, alert dialog, slot.

The README links a live demo hosted separately, which is the fastest way to judge the model quality before cloning anything.

Where the manifest stops matching the pitch

Three things in the package manifest sit oddly against a zero-backend, offline-first, no-data-collection claim, and all three point the same direction: this repository started as a template and grew.

The package is named `next-template` at version 0.0.2 and marked private. That is scaffolding. A project that has shipped three releases, a PWA, four AI features and a GPL-3.0 license file still calls itself `next-template`, which tells you the manifest was never updated after the fork. It is harmless at runtime and confusing for anyone auditing dependencies.

`@prisma/client` at 6.4.1 is in the dependency list. Prisma is a database ORM, and a client-side-only image tool has no database. Either it is a leftover from the template, or there is a server-side plan, or a dependency crept in and stayed. Either way, its presence undercuts the zero-backend claim on first inspection.

`@vercel/analytics` and `@vercel/speed-insights` are also present. These send analytics data to Vercel from the browser, which is a network request your visitors' browsers make. For a project whose central claim is that no data is collected, shipping analytics beacons is a contradiction a reviewer will find in about a minute.

The remaining dependencies are more explicable. `html2canvas` and `cheerio` suggest DOM capture and HTML parsing for some export or comparison path. `luxon` is date handling. `framer-motion`, `embla-carousel-react`, `react-dropzone` and `react-compare-slider` are UI pieces for carousels, drag-and-drop uploads and before/after comparison, which is the natural UI for a background remover. `image-resize-compress` and `react-infinite-viewer` handle large images. A `.Jules/` directory in the tree suggests some of this work was driven by an automated coding assistant.

None of this makes the project bad. It makes the claims worth checking against the code, which is the habit worth forming before you point a browser tab full of model weights at a dependency list this long.

Editorial conclusion

Removerized is a good fit for batch jobs on images you are comfortable keeping local, and the license allows that. GPL-3.0 covers the code, the models carry their own upstream terms, and the README states it plainly, so read both before you ship anything. Two limits decide whether it works for you. Every inference runs on your own CPU through WASM, which is fine for a handful of images and unpleasant for hundreds. And the models are large downloads, with the FP32 BiRefNet Lite variant listed at 224 MB, which is why v1.1.1 spent its release fixing hangs during model download. If you need a server-side pipeline, a hosted API or an unattended batch job, this is the wrong shape of tool. The last push was on 2026-07-09 and v1.1.1 shipped on 2026-04-15.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. yossdotpro/removerized on GitHub