# rembg: background removal as a CLI, Python library, HTTP server or Docker container

> rembg wraps ONNX segmentation models behind a command line, a Python API, a FastAPI server and a container image. It is a good fit when you want background removal inside your own pipeline, and a poor fit when you need a hosted, zero-install service.

**danielgatis/rembg** — Rembg is a tool to remove images background

- Repository: https://github.com/danielgatis/rembg
- Stars: 24,932 · Forks: 2,426
- Language: Python
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/danielgatis-rembg

## What rembg does and who it is aimed at

rembg is a Python tool that removes the background from an image. The README describes four ways to use it: a command line interface, a Python library, an HTTP server, and a Docker container. That range is the point. The same package can be a one-off command on a laptop, a library call inside a batch pipeline, or a service listening on port 7000.

The audience is developers and engineers rather than end users. There is no desktop application in the repository listing, and the README does not document a GUI beyond the Gradio interface that the HTTP server exposes. If you want to drop a photo into a browser and get a cutout back, rembg is the wrong shape: you would be installing Python, picking an onnxruntime backend, and downloading a model before you see anything. If you want to process ten thousand product photos on your own hardware, or call a function from a Python script, the design matches the job.

The models come from the ONNX ecosystem. The default model names in the README are u2net, u2netp, sam, u2net_custom, bria-rmbg and withoutbg. Only the ones the README names are safe to assume; the rest you should confirm from the package itself.

## How the inference pipeline is put together

The mechanism is a segmentation model plus post-processing. rembg loads an ONNX model through onnxruntime, runs the image through it, and produces a mask. The mask is then applied to the original image to make the background transparent, which is why the default output is a PNG.

Several pieces sit on top of that core. Alpha matting, enabled with the -a flag, refines soft edges. Color decontamination, enabled with -dc, is described in the README as removing color fringing from soft edges. Both are optional because both cost time. The -om flag returns only the mask instead of the composited image, which is useful when you want to do your own compositing downstream.

Models are not all bundled. The pyproject.toml lists pooch as a dependency, which is a download manager, and the CLI has a dedicated d subcommand to download models ahead of time. The Dockerfile runs rembg d bria-rmbg during the image build, which tells you the intended pattern: fetch the model at build time so the container does not need network access on first request. The m subcommand migrates models from the legacy ~/.u2net directory, which implies the model storage location changed at some point and older installations need moving.

Extra parameters go through the -x flag as a JSON string. The README shows this for SAM prompts, where you pass a point coordinate and a label, and for a custom model path. That is the extension point when the fixed model list is not enough.

## Installing rembg and removing your first background

The README states the Python requirement as >=3.11 and <3.14, and pyproject.toml pins python to ^3.11 with classifiers for 3.11, 3.12 and 3.13. Install one backend, not several. For CPU-only work:

```bash
pip install "rembg[cpu,cli]"
```

The cpu extra pulls onnxruntime and the cli extra pulls the command line dependencies. If you only need the library and will call it from your own code, `pip install "rembg[cpu]"` is enough.

For NVIDIA hardware the README tells you to check the onnxruntime installation matrix first, then install the gpu extra. It also warns that NVIDIA GPUs may require onnxruntime-gpu, CUDA and cudnn-devel, and points at issue 668 for details. For AMD, install onnxruntime-rocm following AMD's documentation, then install the rocm extra. The pyproject markers matter here: onnxruntime-gpu is marked sys_platform != 'darwin', so it is not available on macOS, and onnxruntime-rocm is marked sys_platform == 'linux'.

Once installed, the shortest path to a result is a single file:

```bash
rembg i path/to/input.png path/to/output.png
```

Omit the output path and rembg writes input.out.png next to the input. If stdout is redirected, as in `rembg i input.png > out.png`, the README states the output goes to stdout instead.

To pick a different model, add -m. To get only the mask, add -om. To process a whole directory, use the p subcommand, and add -w to watch for new or changed files:

```bash
rembg p -w path/to/input path/to/output
```

For a self-hosted endpoint, the s subcommand starts an HTTP server. The README's example binds all interfaces on port 7000, and API documentation is served at /api on that port:

```bash
rembg s --host 0.0.0.0 --port 7000 --log_level info
```

The server also exposes a Gradio UI, which you can turn off with --no-ui; the README says this reduces idle CPU usage. Removal is then a POST with a file, or a GET with a url parameter, against /api/remove.

## Where rembg stops being the right tool

The dependency chain is the first real constraint. rembg does not ship its own inference runtime; it depends on onnxruntime, onnxruntime-gpu or onnxruntime-rocm depending on your extra. The README is explicit that if rembg[gpu] does not work and you cannot install CUDA or cudnn-devel, the fallback is rembg[cpu] with onnxruntime. That is a documented failure path, not a hypothetical one, and it is the most common place an installation stalls.

Platform coverage is uneven. macOS gets no GPU extra at all, because onnxruntime-gpu is excluded on darwin. ROCm is Linux-only. So a mixed team of Mac laptops and Linux GPU boxes will not run the same backend everywhere, and the CPU path becomes the common denominator.

Model quality is another boundary. The README does not publish accuracy numbers or a comparison between models, so choosing between u2net, u2netp, bria-rmbg or a SAM prompt is an empirical exercise on your own images. u2netp is the smaller variant, and smaller usually means faster and less precise, but the README does not state the trade-off in those terms.

The withoutbg model is a different case entirely. It is a cloud API: you set WITHOUTBG_API_KEY or pass api_key through -x, and the README mentions 50 free credits on signup. Once you use it, your images leave your machine. If the reason you picked rembg was to keep images local, that model defeats the purpose.

Finally, the batch and watch subcommands are file-oriented. There is no documented queue, retry policy or job persistence. For a large one-off batch that is fine; for a long-running service you will be building the surrounding machinery yourself.

## rembg compared with hosted background removal APIs

The obvious alternative is a hosted API such as the PhotoRoom Remove Background API, which is listed in the README as a sponsor. The difference in approach is where the model runs. A hosted API takes an HTTP request with an image and returns a cutout; there is nothing to install, no onnxruntime matrix to consult, and no model to download. You pay per call and you send the image to someone else's servers.

rembg inverts all three of those properties. You install it, you resolve the runtime yourself, and the image stays on your machine unless you deliberately choose the withoutbg model. The cost moves from per-call pricing to compute, disk for models, and the engineering time to keep the environment working.

That trade is not close for every team. If your volume is low and your images are not sensitive, a hosted API will get you to a result in minutes and rembg will take an afternoon. If your volume is high, or your images cannot leave your infrastructure, or you need to run offline, the local model is the only option that satisfies the constraint. The repository also points at a Hugging Face Space and a Streamlit Community Cloud app for people who want to try the model without installing anything, but those are demos, not deployment targets.

A second comparison worth naming is SAM. Within rembg itself, the sam model takes a prompt through -x with a point coordinate and a label, which makes it interactive rather than automatic: you tell it where the subject is. The automatic models need no such hint. That is a real functional split inside the same tool, and the README's plants example is the only guidance on how to use it.

## Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-08, the same day as the v2.0.84 release. Releases v2.0.82, v2.0.83 and v2.0.84 all landed in September 2026, so the project is receiving changes. That does not tell you anything about the size of those changes; the release notes are not available, so treat the cadence as activity rather than as a stability guarantee.

The practical upgrade cost sits in the dependency pins. pyproject.toml requires numpy ^2.3.0, pillow ^12.1.0, scikit-image ^0.26.0 and scipy ^1.16.3, with onnxruntime ^1.23.2 for the CPU backend. Those are recent major versions of widely shared libraries. If your environment already pins older numpy or pillow for another component, rembg will force a resolution conflict. That is the most likely reason an upgrade breaks something unrelated to background removal.

The licence is MIT, stated in pyproject.toml, in the LICENSE.txt file at the repository root and in the README badge. MIT is permissive: it allows commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That covers rembg's own code. It does not automatically cover the model weights. The models are downloaded separately, and the README does not state the licence of each one. If you ship a product that depends on a specific model, check that model's terms separately; this is a factual gap in the documentation, not a legal opinion.

One more operational detail: the Dockerfile runs `rembg d bria-rmbg` at build time and exposes port 7000. docker-compose.yml builds the same image, runs the s subcommand, and takes PUBLIC_PORT and REPLICAS_COUNT from a .env file in the root folder. Scaling replicas is therefore a compose setting, but the README does not discuss what happens to model loading when several replicas start at once.

## Conclusion

Adopt rembg if you want background removal inside your own code, batch jobs or a self-hosted endpoint, and you are willing to manage Python 3.11 to 3.13, an onnxruntime backend and model downloads. Do not adopt it if you need a zero-install web tool, a desktop GUI, or a guarantee that a specific model will work on your hardware without testing. Before committing, verify three things: that onnxruntime or onnxruntime-gpu installs cleanly on your platform, that the model you intend to use is downloadable in your network, and that the alpha matting or color decontamination flags actually improve your specific images rather than adding processing time.

## FAQ

### What is rembg?

rembg is a tool to remove image backgrounds, written in Python. The README says it can be used as a CLI, a Python library, an HTTP server or a Docker container, and it runs ONNX segmentation models through onnxruntime.

### Is rembg free?

The code is MIT licensed, so it is free to use and modify under those terms. Model weights are downloaded separately and the README does not state their licences. The withoutbg model is a cloud API with 50 free credits on signup, so that particular model is not free beyond the credits.

### How do I install rembg?

Install one backend extra with pip: rembg[cpu] for the library, rembg[cpu,cli] for the library plus the command line, or the gpu and rocm equivalents. The README requires Python >=3.11 and <3.14, and for NVIDIA hardware it tells you to check the onnxruntime installation matrix first.

### How do I use rembg from Python?

The README documents the Python library as one of the four supported interfaces, installed with the cpu extra alone, without the cli extra. No Python code sample is given in the README, so the exact function names are not something this article can state.

### How does rembg compare with remove.bg?

rembg runs the model on your own machine or server, so images stay local unless you choose the withoutbg cloud model. A hosted service like remove.bg or the PhotoRoom API takes an HTTP request and returns a cutout with nothing to install, but the image is sent to their servers. The README does not publish accuracy comparisons between rembg and hosted services.

### Is rembg safe to run?

The code is MIT licensed and runs locally, so images are not sent anywhere unless you select the withoutbg cloud model. The models themselves are downloaded from external sources, and the README does not document checksum verification for those downloads, so that is the part to check on your own network.

## Sources

- [danielgatis/rembg on GitHub](https://github.com/danielgatis/rembg)
- [Issues](https://github.com/danielgatis/rembg/issues)
- [License: MIT](https://github.com/danielgatis/rembg/blob/main/LICENSE)
- [README](https://github.com/danielgatis/rembg/blob/main/README.md)
- [Releases](https://github.com/danielgatis/rembg/releases)

---

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