Open-source alternatives to remove.bg: 3 image background removal tools compared
Replacing remove.bg with self-hosted software means the image never leaves your machine, but the segmentation model, the runtime and the model downloads become yours to operate. danielgatis/rembg is the one most readers should look at first; nadermx/backgroundremover is the only candidate here that also handles short video, and pymatting/pymatting is a matting library rather than a background remover.
What remove.bg does, and why people look elsewhere
remove.bg is a hosted service that cuts the background out of a photo and returns the subject on a transparent or replaced background.
- every image is uploaded to the vendor's servers to be processed
- the segmentation model is the vendor's and its output cannot be run on your own machine
- the result arrives as an image through the vendor's service, so a batch of edits depends on that service being reachable
The candidates at a glance
| Project | Licence | Maintenance | Language | GitHub stars | Install |
|---|---|---|---|---|---|
| danielgatis/rembg | MITPermissive: commercial use allowed | Commits in the last six monthsLast push October 10, 2026 | Python | 25,147 | Command documented |
| nadermx/backgroundremover | MITPermissive: commercial use allowed | Commits in the last six monthsLast push July 10, 2026 | Python | 8,121 | Command documented |
| pymatting/pymatting | MITPermissive: commercial use allowed | Commits in the last six monthsLast push September 8, 2026 | Python | 1,922 | Command documented |
Each alternative in detail
danielgatis/rembgRembg is a tool to remove images background
- Best for
- A pipeline that has to cut out backgrounds on your own machines, whether that means a Python call inside a batch job, a command line over a folder, or an HTTP endpoint your own services can reach.
- What you give up
- You own the whole stack: Python 3.11 to 3.13, an onnxruntime backend chosen for your hardware, and model files fetched at runtime. There is no interactive editor, so a bad edge has to be handled by the alpha matting and colour decontamination flags rather than by brushing on the mask, and nothing runs until the models are reachable from your network.
- First install step
- Full setup guide
pip install "rembg[cpu,cli]"
nadermx/backgroundremoverBackground Remover lets you Remove Background from images and video using AI with a simple command line interface that is free and open source.
- Best for
- Short video as well as still images, on a workstation with a CUDA-capable GPU, where a whole folder of shots can be processed in one pass instead of file by file.
- What you give up
- It is built on PyTorch and ffmpeg, so a machine without a CUDA build of PyTorch falls back to the CPU and video jobs get slow, and the first run pulls the u2net models into a local cache. The Docker route needs a larger shared memory setting for video, and the alpha matting parameters expose an erosion size that has to be tuned per subject to get a usable edge.
- First install step
- Full setup guide
pip install --upgrade pip pip install backgroundremover
pymatting/pymattingA Python library for alpha matting
- Best for
- A research or image-processing pipeline where you already hold a trimap marking pixels as background, foreground or unknown, and you want a real alpha estimate rather than a binary cut-out.
- What you give up
- It never finds the subject for you: without a hand-drawn trimap of the same size as the image there is nothing to estimate from, so it is not a drop-in replacement for an automatic service. GPU acceleration covers foreground estimation only, not the alpha estimation itself, and the closed-form and KNN methods carry a real compute cost on large images.
- First install step
- Full setup guide
git clone https://github.com/pymatting/pymatting cd pymatting pip3 install . pip3 install -r .[test] pytest
Automatic cut-out, batch cut-out and trimap-driven matting
Three candidates, three different answers to the question of what decides which pixels belong to the subject.
danielgatis/rembg is the direct one. It wraps pre-trained ONNX segmentation models and exposes the same capability four ways: a command line, a Python API, a FastAPI server and a container image. The command line covers the cases a pipeline actually hits: single files, whole folders, an HTTP server, a raw RGB pixel stream, plus housekeeping subcommands for pulling models down in advance and moving them out of an older directory. Flags control the interesting behaviour, including returning the mask on its own, running alpha matting so soft edges survive, and decontaminating colour fringing along the cut. Model choice is a flag too, so speed and quality can be traded per job.
nadermx/backgroundremover runs the same family of u2net models through PyTorch rather than through an ONNX runtime, and it extends the job to video as well as images. The additions that matter are batch handling over folders and alpha matting with exposed parameters: a foreground threshold, a background threshold and an erosion size that decides how hard the edge looks. It detects a GPU and falls back to the CPU when it cannot find one, which is convenient and slow.
pymatting/pymatting is a different tool entirely. It solves alpha matting, the harder problem behind a clean cut-out: estimating a continuous alpha channel where hair, fur and motion blur make the answer ambiguous. Its input is an image plus a trimap, a single-channel image of the same size marking pixels as background, foreground or unknown, and the unknown band is what the algorithm solves for. Six matting methods and two foreground estimators are implemented, with a fast multithreaded KNN search and Numba for the CPU path.
What changes when the image stops leaving your network
remove.bg cuts the background out on the vendor's servers, which is exactly why people start looking for something else: every image leaves your network, the segmentation model belongs to the vendor and cannot run on your own machine, and a batch of edits only finishes while that service is reachable.
The first two candidates answer that with different amounts of work. danielgatis/rembg and nadermx/backgroundremover keep the whole thing on your hardware, so the images never move and a batch runs as long as your own machine is up. The price is that the model becomes a downloaded artefact you have to obtain, store and keep working, and that the quality of the cut is bounded by a general-purpose segmentation model rather than by a service tuned for one job.
pymatting/pymatting changes the question instead of the infrastructure. The subject is not detected, it is declared: you draw the trimap, the library estimates the alpha inside the unknown band. That is a better answer for quality on hard edges and a worse answer for throughput, because a person is in the loop for every image.
What was left out, and why, matters on a page like this. The hosted background removal services that share remove.bg's shape are closed, so there is no code to point a reader at. The interactive editors that let a person brush over a mask by hand are largely desktop software rather than something a pipeline can call. The README of rembg also points at a browser demo and a hosted notebook as ways to try the tool; those are community instances and demos, not a deployment you control.
What each one costs to run
rembg has the smallest surface area and the sharpest edges. It needs Python 3.11 through 3.13, and the runtime is chosen per machine: a CPU build for ordinary hardware, a separate GPU build for NVIDIA cards that also expects CUDA and cudnn development packages, and a ROCm build for AMD. If the GPU package will not install, the CPU path still works, just slower. Models are fetched on demand, so the first job in a fresh environment spends time downloading, and a network that cannot reach the model host fails that job outright. Running it as a service means the FastAPI server or the container image, which is the piece that replaces a hosted API without adding a database.
backgroundremover is heavier by design. It needs PyTorch and torchvision, ffmpeg for the video path, and the Python development headers a PyTorch build expects. Video processing is where it bites: the work is split across processes, so the container needs a larger shared memory setting than the default, and the models are downloaded again on every run unless you mount a directory to keep them. A machine without a CUDA build of PyTorch still works, on the CPU, and the documentation says so plainly.
pymatting is a library rather than a service, so the operational cost is a dependency set: NumPy, Pillow, SciPy and Numba, plus CuPy or PyOpenCL for the optional GPU foreground estimation. Its compute cost lands on your own hardware at request time, and the closed-form and KNN methods are the expensive ones on large images.
Licences, and the models that sit underneath them
All three repositories are MIT licensed, which is the easy case: you can run them inside a company, modify them and host the modified version on your own infrastructure without an obligation to publish your changes. None of the three carries a copyleft condition, so the network-hosting question that catches out some other categories of open-source software does not arise here.
The models are the part worth reading carefully. rembg and backgroundremover both load pre-trained segmentation weights at runtime instead of shipping them in the source tree, so the terms attached to those weights are a separate file to read before customer images go through them. The u2net weights that backgroundremover pulls on its first run come from the project itself, while rembg keeps its models in a per-user directory and provides a dedicated command for moving them out of an older location, which is a fair hint that where they live and under what terms is not always obvious.
One configuration undoes the point of the rest. rembg can be pointed at a hosted backend and called with an API key, which is convenient and sends the image back out over the network, so it should not be the default in a pipeline whose reason for existing is that images stay inside your perimeter.
Choosing by scenario, and the weaker choice in each pairing
For a solo developer with a folder of product photos, rembg on the CPU is the shortest path: install the CPU extra and the command line, and the folder subcommand does the work. For a small team with a CUDA machine and a mix of stills and short clips, backgroundremover covers both, with GPU detection and the erosion parameter as the two things to tune. For a company with data residency rules, both keep images local, and the decision comes down to whether you need the HTTP endpoint rembg provides or a container you can hand to a platform team.
pymatting/pymatting is the pick only when a trimap exists or can be produced, and it is the weakest of the three for automatic cut-outs, because the segmentation step it does not do is the step most people are buying. Its strongest argument is quality: when a subject has soft edges and an automatic model leaves a halo, a hand-drawn trimap with a proper alpha estimator can produce a better result than any one-shot segmenter.
The weaker choice is worth naming in each case. rembg over backgroundremover when video matters, because rembg does not do video. backgroundremover over rembg when you want an HTTP endpoint, because backgroundremover is a command line tool. pymatting over either when nobody is going to draw trimaps, because then there is no input for it.
Bottom line
Choose rembg for images on your own machines, backgroundremover when short video is in scope and you have a CUDA box, and pymatting only for trimap-driven alpha work where quality beats throughput. Before committing, run one hard-edged photo through the model you intend to use, confirm the weights download inside your network, and check the licence of the weights themselves.
Sources
Was this useful?