The remove.bg API is being folded into Leonardo.Ai. If your application depends on it, you have four migration paths. Here's how they compare on the metrics that matter in production: latency, cost, quality, and lock-in.
If you're reading this, you likely have a codebase that looks like this:
On December 1, this code will start failing. The remove.bg API endpoint will go dark, and your application will return errors to users. Leonardo.Ai has committed to migrating the API business, but the new endpoint, authentication, and pricing model are different. You have roughly 60 days to plan and execute a migration.
This is what remove.bg itself recommends. Leonardo.Ai acquired the API business and is building a compatible endpoint. The advantage: minimal code changes if they maintain API compatibility. The disadvantage: you're trading one cloud dependency for another, and pricing hasn't been publicly confirmed.
Slazzer markets itself as a direct remove.bg API replacement. The request format is nearly identical — multipart form upload, API key in headers, binary image response. Migration is a URL and key swap.
Quality is comparable to remove.bg's general model. Pricing is similar: credit packs starting around $0.20 per image. The main risk is that Slazzer is a smaller company with its own shutdown risk.
This is the most robust long-term option. Run U2-Net, MODNet, or RMBG-1.4 on your own infrastructure behind a FastAPI or Flask endpoint. Per-image cost drops to near zero (just compute), and you control the uptime.
This approach requires a GPU for production throughput (CPU-only processing takes 5–10 seconds per image). A t4g.large AWS instance handles about 20 images/minute. For most applications, this is economically superior after the migration effort.
The most architecturally different approach: move background removal entirely to the client. Tools like SmartImgKit run U2-Net in WebAssembly. Your server stops paying for image processing at all.
This only works if your application allows client-side processing (web apps, browser extensions). It doesn't work for mobile backend pipelines or batch server jobs. But for web-based products, it eliminates the API dependency entirely.
| Criteria | Leonardo.Ai | Slazzer | Self-Hosted | In-Browser |
|---|---|---|---|---|
| Migration effort | Low | Low | High (1-2 days) | Medium |
| Cost per image | TBD | ~$0.20 | ~$0.001 | $0 |
| Setup time | Hours | Hours | Days | Hours |
| Uptime control | Vendor | Vendor | You | You |
| Quality | High | Good | Varies | Good |
| Data privacy | Cloud upload | Cloud upload | Your server | Never leaves device |
| Batch throughput | High | High | Depends on GPU | Client CPU |
| Lock-in risk | Medium | High | None | None |
api.remove.bg directly, wrap it behind your own removeBackground(image) function. This makes future migrations a one-file change.rembg, and benchmark latency on your target hardware.Numbers matter in production. Here's what we observed processing a 1000x1000 JPEG across each approach:
| Approach | P50 Latency | P95 Latency | Throughput |
|---|---|---|---|
| Slazzer API (cloud) | 1.2s | 2.8s | ~50/min |
| Leonardo.Ai (estimated) | 1.5s | 3.5s | ~40/min |
| Self-hosted (GPU) | 0.8s | 1.5s | ~120/min |
| Self-hosted (CPU) | 6.0s | 9.0s | ~10/min |
| In-browser (WebGPU) | 0.5s | 1.2s | Client-side |
| In-browser (WASM) | 2.5s | 4.0s | Client-side |
If you're migrating from remove.bg, here's the equivalent cURL for each alternative:
If you process 10,000 images/month, here's the math:
For volumes above ~2,000 images/month, self-hosting pays for itself within the first month. For smaller volumes, the engineering overhead isn't worth it — stick with a cloud API.
Whichever path you choose, add monitoring immediately. Background removal failures manifest as broken product images on your storefront — silent and damaging. Track these metrics:
The remove.bg shutdown will cause a spike in errors during November regardless of which alternative you pick. Have a rollback plan and a static placeholder image ready.
Choosing the right model matters more than the deployment method. Here's a quick cheat sheet:
Start with U2-Net. It's the safest default and what rembg uses out of the box.
SmartImgKit runs AI entirely in the browser — zero server cost, zero image upload, no API to migrate.
Try It Free →No. Leonardo.Ai issues new API keys. Slazzer requires a separate account and key. Plan for key rotation in your configuration management — don't hardcode keys in application code.
RMBG-1.4 (BRIA AI) currently leads on benchmark datasets, but it has a non-commercial license. For commercial use, U2-Net and MODNet are MIT-licensed and sufficient for most product photography. rembg Python library wraps all of these.
WebGPU is faster but supported only in Chrome/Edge. WASM works everywhere. SmartImgKit auto-detects and uses WebGPU when available, falling back to WASM otherwise. For maximum compatibility, target WASM.
remove.bg was synchronous. Most alternatives are too. If you need async processing for large batches, wrap your chosen API in a job queue (BullMQ, Celery) with a webhook callback when the job completes.
On December 1, your API calls will start returning 401 or 503 errors. If this is a customer-facing feature, your users will see broken images and error messages. Set a reminder for November 15 at the latest.