# Remove Background





The  Route can be used to remove the background of an image. This route leverages Bria's newest model, RMBG 2.0. For more details and to explore the model, check out the Hugging Face demo.




This endpoint includes granular content moderation controls to ensure safe usage across all stages of processing:
  
-  – Scans the uploaded image and stops processing if inappropriate or restricted content is detected.
-  – Evaluates the generated image and blocks the response if it violates safety guidelines.





The Bria API currently supports only JPEG and PNG files in RGB, RGBA, or CMYK color modes. When the file is of a different type or color mode, the status code 415 will be returned.





This endpoint returns an image where the background is removed, and the foreground remains with varying levels of transparency, allowing for smoother edges and more natural blending when placed over different backgrounds. Additionally, this unique output provides developers with the flexibility to binarize the result—transforming it into a binary mask—by setting a custom transparency threshold according to their specific use case. A binary mask is an image where pixels are either fully visible (foreground) or fully transparent (background), commonly used in visual generative AI and image processing pipelines. This capability enables seamless integration into workflows that require clear separation between subject and background, while still offering control over how strict this separation should be.


Below is a simple Python script to demonstrate how you can binarize the output image from the API. This allows you to set your own threshold to determine which areas are considered "foreground" and which are "background."

  

Endpoint: POST /remove_background

## Header parameters:

  - `api_token` (string, required)

## Request fields (application/json):

  - `image` (string, required)
    The image that you would like to remove the background from.
Supported input types:  
-   
-  pointing to an image file that is publicly accessible and available at the time of processing.  

Accepted formats: , , , .

  - `preserve_alpha` (boolean)
    Controls whether partially transparent areas from the input image are retained in the output after background removal, if the input includes an alpha channel.
- When true: Partially transparent pixels preserve their original alpha values in the output.
- When false: All non-background areas in the output are rendered fully opaque.
- Has no effect if the input image does not include an alpha channel.

  - `sync` (boolean)
    Specifies the response mode.
  - When  (default), the request is processed asynchronously: the API immediately returns a status URL to track progress.
  - When , the request is processed synchronously: the API hold the connection open until the proccess is complete and then returns the final image URL in the response.

  - `visual_input_content_moderation` (boolean)
    When enabled, applies content moderation to input visual.

Expected behavior:
- Processing stops if the image fails moderation.
- Returns a 422 error with details about which parameter failed.

  - `visual_output_content_moderation` (boolean)
    When enabled, applies content moderation to result visual.

Expected behavior:
- If the modified image fails moderation, returns a 422 error.

## Response 200 fields (application/json):

  - `result` (object, required)

  - `result.image_url` (string, required)

  - `request_id` (string, required)

## Response 202 fields (application/json):

  - `request_id` (string, required)

  - `status_url` (string, required)

## Response 400 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 123

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 401 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 123

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 403 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 123

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 404 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 123

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 415 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 123

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 422 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 123

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 429 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 123

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 460 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 123

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 5XX fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 123

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)