Google Virtual Try-On API Pricing: $0.1075

A garment flat lay can become an on-body preview with one person photo and one garment image. Google Virtual Try-On returns one image per request, so its image budget is straightforward to calculate.

TL;DR

The price is $0.1075 per image, billed by the requested image count; view budget calculations. Set num_images to 1. For additional garments, people or candidates, submit separate requests. There is no prompt field: the two input images define the try-on.

Unit price and budgets

Planned result images	Calculation	Budget
1	1 × $0.1075	$0.1075
10	10 × $0.1075	$1.075
100	100 × $0.1075	$10.75
1,000	1,000 × $0.1075	$107.50

For example, 10 tops shown on 3 people produce 30 combinations. One result per combination costs $3.225. A second candidate for each combination brings the plan to 60 images and $6.45. These budgets multiply the image count by the unit price; they do not include the work of selecting results or preparing assets.

What one result shows

Upload images to try it →; no prompt required.

This result keeps the gray background, jeans and white shoes while replacing the white tank top with the striped T-shirt. It lets you inspect the color, sleeve length and overall outfit. Judging physical fit still requires the garment's measurements. The examples page shows the person, garment and result together so changes are easier to locate.

Keep the first round small

Start with a person photo that shows the body clearly and a flat-lay or hanging garment photo with complete edges. Request one result with num_images: 1, inspect the neckline, hem and areas around the hands, then decide whether another candidate is useful. Repeating the same inputs adds to the planned image count, so include those candidates in your budget.

The input has no prompt field and no resolution or quality tier for choosing a price. The integration guide covers the fields and request format.

Allocate the budget by outfit combination

Build the image count from combinations you actually intend to show. List the garments and the people needed for each garment, then include only those pairings in the plan. To change the person, keep the garment image and replace the person image. To change the garment, keep the person image and replace the garment image. Submit each pairing separately; increasing num_images cannot batch the combinations.

The earlier plan of 10 tops and 3 people assumes every combination is needed. If you only need one suitable person for each item, choose that person before counting requests. You do not need to run every person automatically. Recording the pairing also makes it clear whether later spending covers another outfit or an extra candidate for an existing one.

Keep a separate allowance for candidates. Review the first result for correct color and cut, acceptable neckline and hem, and no prohibited changes to the person or shoes. Stop adding candidates once a combination meets the brief. Where it does not, decide whether the input needs changing first. Adding candidates to the entire batch is a different plan from revisiting a few combinations. Additional requests use the same unit price; a request budget does not promise a corresponding number of usable deliverables.

Parameters and billing boundaries

A try-on needs a person image and a garment image, which together produce one result. The $0.1075 unit price applies to result images, not a separate charge for each input. num_images currently only accepts 1. There is no prompt, quality or resolution field that switches the price.

These calculations plan ordinary submissions. The public pricing material does not establish complete settlement or refund rules for failed tasks, submission timeouts or repeated requests, so do not budget those situations as free. If submission returned a taskId, keep querying that task. A browser stopping its wait or losing its connection does not establish that the server created no task. Avoid repeated submissions merely to wait for a result, so the budget and task list remain aligned.

Select inputs before spending on candidates

The person photo should show the area being dressed. The garment image should include its neckline, sleeves and hem. If a product photo crops out the cuffs, repeated candidates cannot supply reliable evidence about that product. Find a complete photo before judging sleeve length. A front-facing pose, visible body outline and clean background are selection recommendations, not guarantees that an accepted request will produce a suitable image.

Write down which regions must remain unchanged. For a top, the trousers and shoes may be part of an outfit that must stay intact; the dress example changes the shoes. A brief requiring exact accessories needs time for individual review. The API budget excludes preparing product photos, reviewing the person's likeness and retouching results. A successfully returned image may still be rejected because its product details do not meet the brief.

Save selected results with both corresponding inputs and the reason for choosing them. You can reuse that standard when adding people or garments. Physical sizing, fabric thickness and comfort still require product data and real fit information. More candidates cannot supply those facts.

FAQ

Can I request several images at once?

The supported value of num_images is currently 1. Submit separate tasks for additional candidates.

Is pricing based on the number of uploads?

Pricing follows the requested result count. The person and garment images are the two inputs needed for one try-on.

Can I use it without a prompt?

Yes. It takes a person image and a garment image, with no prompt field.

Can the result measure garment fit?

Use it to inspect the appearance of an outfit. Sizing decisions still need garment measurements and physical fit information.

Further reading

API integration · Examples and input selection · Google Virtual Try-On