images.generate types advertise output_format="webp" for gpt-image-2, but API ignores it and returns PNG

[pedrobarretocw]

Confirm this is a Node library issue and not an underlying OpenAI API issue

• This is an issue with the Node library

Describe the bug

The SDK type ImageGenerateParamsBase declares

output_format?: 'png' | 'webp' | 'jpeg'

as valid for all GPT image models. In practice, when calling images.generate with model: "gpt-image-2" and output_format: "webp", the API returns PNG-encoded bytes in data[0].b64_json regardless of the requested format. JPEG is honored correctly, so the SDK is sending the field — the API silently ignores webp for this model.

The SDK type therefore lies to callers: the .jpeg path works, the .webp path returns PNG bytes with no error and a misleading filename if you derive the extension from the request.

Two acceptable fixes:

1. SDK side — narrow output_format to 'png' | 'jpeg' for gpt-image-2, surfacing the limitation at compile time.
2. API side — honor output_format: "webp" for gpt-image-2.

To Reproduce

1. Call images.generate with model: "gpt-image-2", output_format: "webp", any quality.
2. Decode result.data[0].b64_json to bytes.
3. Inspect the first 8 bytes — they are 89 50 4E 47 0D 0A 1A 0A (PNG magic) instead of 52 49 46 46 .. .. .. .. 57 45 42 50 (RIFF/WEBP).
4. Repeat with output_format: "jpeg" — bytes start with FF D8 FF (JPEG magic) as expected.

Reproduces identically on quality: "auto" | "low" | "medium" | "high".

Code snippets

import OpenAI from "openai";
const client = new OpenAI();

const r = await client.images.generate({
  model: "gpt-image-2",
  prompt: "solid red square",
  size: "1024x1024",
  quality: "low",
  output_format: "webp",
  output_compression: 30,
  n: 1,
});

const bytes = Buffer.from(r.data[0].b64_json, "base64");
console.log(bytes.subarray(0, 4).toString("hex")); // "89504e47" → PNG, not WEBP

Raw curl confirms it is API-side, not SDK-side:

curl -X POST https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer \$OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model":"gpt-image-2","prompt":"solid red square",
    "size":"1024x1024","quality":"low",
    "output_format":"webp","output_compression":30,"n":1
  }' | jq -r '.data[0].b64_json' | base64 -d | xxd | head -1
# → 00000000: 8950 4e47 ...   (PNG magic, not RIFF/WEBP)

OS

Linux (Deno 1.46+)

Node version

N/A — running Deno via `jsr:@openai/openai@^6`

Library version

openai 6.35.0

[jbeckwith-oai]

I dug into this and reproduced the issue with plain Node.js fetch, independent of openai-node.

Repro request:

await fetch("https://api.openai.com/v1/images/generations", {
  method: "POST",
  headers: {
    authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
    "content-type": "application/json",
  },
  body: JSON.stringify({
    model: "gpt-image-2",
    prompt: "solid red square, flat color, no text",
    size: "1024x1024",
    quality: "low",
    output_format: "webp",
    output_compression: 30,
    n: 1,
  }),
});

Observed result:

requested webp -> response output_format webp -> decoded bytes are png
magic: 89 50 4e 47 0d 0a 1a 0a ...

requested jpeg -> response output_format jpeg -> decoded bytes are jpeg
magic: ff d8 ff e0 ...

So the SDK is not dropping or mistranslating the request field. The endpoint receives output_format: "webp" and responds successfully, but the returned data[0].b64_json payload is PNG-encoded. The response metadata also says output_format: "webp", which makes this especially easy for callers to mis-handle if they derive filenames or MIME types from the request/response field.

SDK-side source check:

• images.generate forwards the request body directly to /images/generations.
• ImageGenerateParamsBase.output_format is generated as 'png' | 'jpeg' | 'webp' | null for the shared image generation params.

Root cause:

The API/model behavior and the generated spec/SDK contract are out of sync for gpt-image-2 / gpt-image-2-2026-04-21.

The right fix depends on intended product behavior:

1. If gpt-image-2 is supposed to support WebP, the API/backend should encode the returned image as WebP and ensure response metadata matches the actual bytes.
2. If gpt-image-2 does not support WebP, the source OpenAPI/spec should model that limitation so generated SDKs do not advertise webp for those models. Ideally the API should also reject unsupported output_format: "webp" rather than silently returning PNG while reporting WebP.

Given the plain-fetch repro, this is not an openai-node transport bug; it is either an API behavior bug or a spec-contract bug that surfaces in generated SDK types.