Transparent GPT Image 2.5 assets: How should you choose format and compression?

General
1

When a generated image has to leave the model and enter a product pipeline, “transparent” and “compressed” are different decisions. For gpt-image-2.5-sunburst and gpt-image-2.5-flare, the Image API documentation’s transparent-background recipe is explicit: set background: "transparent", then choose output_format: "png" or "webp".

That makes PNG the conservative starting point. PNG is the documented default, and the guide does not attach output_compression to it. Choose it when your handoff values the default format and you do not need the documented compression control.

Choose WebP when you want transparency and also want to tune the documented compression setting. The guide says output_compression accepts 0–100% for JPEG and WebP, so WebP is the transparent option in this pair with that control. This is a configuration distinction, not a promise about file size, visual fidelity, alpha handling, or browser support; measure those in your own delivery targets.

Keep JPEG out of the transparency decision. The guide lists JPEG as requestable and says it can be faster than PNG when latency matters, but its transparent-output instruction names only PNG and WebP. Compression support for JPEG therefore does not make JPEG a documented transparent-output choice.

A practical sequence is: set the background requirement first; select PNG or WebP; then, if WebP is your choice, tune compression for the actual handoff. For final assets, compare higher quality settings as the guide recommends, balancing detail, latency, and cost. This keeps a model-specific API decision from turning an unrelated compression knob into a false claim about transparency.

2

For an automated asset workflow, I would make the transparency requirement survive fallback—not just the first request. The documented configuration for gpt-image-2.5-sunburst and gpt-image-2.5-flare gives a concrete boundary for the tool wrapper: a transparent job must retain background: "transparent" and a PNG or WebP output choice.

My proposed rule is to validate the assembled request after any fallback logic runs. If a WebP job switches to PNG, remove output_compression rather than carrying that setting across: the guide documents it for JPEG and WebP, not PNG. If a latency-oriented fallback proposes JPEG, stop and surface the conflict instead of silently relaxing the transparent-asset requirement. These are application-side guardrails, not claims about how the API rejects conflicting parameters.

That also gives you useful local tests without generating images: a transparent WebP-to-PNG fallback should preserve the background setting and omit compression; a transparent-to-JPEG fallback should never reach dispatch. Passing those tests establishes request-policy consistency only. Whether the delivered asset meets the visual handoff still needs a separate check.