API Error: 400 with "messages.31.content.4.image.source.base64.data: Image does not match the provided media type image/jpeg"

Im seeing the same error with both Playright MCP and Chrome Devtools MCP.

Both occur when taking an image.

I am also using Chrome Devtools MCP too, and it makes same situations.

same here...

same here......

Same here...
And after this happens, the session becomes completely un-resumable...

∴ Thinking… Let me get a screenshot for better visual context. ⏺ figma-desktop - get_screenshot (MCP)(nodeId: "764:15337", clientLanguages: "dart", clientFrameworks: "flutter") ⎿  [Image] ⎿  API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.7.content.5.image.source.base64.data: Image does not match the provided media type image/jpeg"},"request_id":"req_011CVLnDBcHiry2xNaa6FENy"} 12:44 PM <synthetic> > what happend? ⎿  API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.7.content.5.image.source.base64.data: Image does not match the provided media type image/jpeg"},"request_id":"req_011CVLnHNz1iLi1Um5CNiHJ2"} 12:45 PM <synthetic>

Yep, completely annoying and breaks my workflow

Additional Evidence: Root Cause Identified with Playwright MCP

I can confirm this bug with Playwright MCP and have identified the root cause.

Investigation

I created a debug script that directly communicates with the Playwright MCP via stdio (bypassing Claude Code) to inspect what the MCP actually returns.

What the MCP Returns (CORRECT ✅)

{
  "type": "image",
  "data": "iVBORw0KGgoAAAA...",  // PNG magic bytes
  "mimeType": "image/png"          // Correctly declared as PNG
}

The Playwright MCP is correctly returning PNG data with mimeType: "image/png".

Root Cause

Claude Code appears to ignore the mimeType field from the MCP response and either:

• Hardcodes media_type: "image/jpeg" when sending to the Anthropic API, OR
• Defaults to image/jpeg when the field is missing/not read

This causes the API to reject the request with:

API Error: 400 {"type":"error","error":{"type":"invalid_request_error",
"message":"messages.15.content.3.image.source.base64.data: Image does not
match the provided media type image/jpeg"}}

Reproduction Steps

1. Configure Playwright MCP (mcr.microsoft.com/playwright/mcp)
2. Navigate to any page: browser_navigate({ url: "https://example.com" })
3. Take PNG screenshot: browser_take_screenshot({ type: "png" })
4. Session crashes with the media type mismatch error

Note: Blank page screenshots sometimes work, but screenshots of actual content consistently trigger the bug.

Workaround

Explicitly request JPEG format to match Claude Code's expectation:

browser_take_screenshot({ type: "jpeg" })

This works because the MCP returns mimeType: "image/jpeg" for JPEG screenshots, which matches what Claude Code sends to the API.

Environment

• macOS Darwin 25.1.0
• Claude Code v2.0.47
• Playwright MCP: mcr.microsoft.com/playwright/mcp (Docker)

Debug Script

I have a Node.js debug script that reproduces this and inspects the raw MCP responses. Happy to share if it would help with debugging.

---

Expected Fix: Claude Code should read and respect the mimeType field from MCP image responses when constructing API requests.

I can confirm this bug affects the browser MCP (@browsermcp/mcp) as well. The browser MCP correctly returns mimeType: "image/png" in its screenshot response, but Claude Code ignores this and hardcodes media_type: "image/jpeg" when sending to the Anthropic API.

Impact: The browser MCP's browser_screenshot tool doesn't accept any format parameters (arguments: z.object({})), so the workaround of requesting JPEG format doesn't apply here. This makes browser screenshots completely unusable in Claude Code.

Root Cause Confirmed: In the browser MCP source (node_modules/@browsermcp/mcp/dist/index.js:542):

return {
  content: [{
    type: "image",
    data: screenshot2,
    mimeType: "image/png"  // Correct PNG declaration
  }]
};

Request: Please fix Claude Code's MCP response handler to respect the mimeType field from MCP tool responses instead of hardcoding JPEG. This would fix the issue for all MCPs (browser, Figma, Playwright, etc.) at once.

Can confirm this issue still exists in Claude Code v2.0.50 (latest) with Chrome DevTools MCP on Linux.

Environment:

• Claude Code version: 2.0.50
• Platform: Linux (6.14.0-35-generic)
• MCP: Chrome DevTools (built-in)
• Tool: mcp__chrome-devtools__take_screenshot

Error:
API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.1.content.6.image.source.base64.data: Image does not match
the provided media type image/jpeg"},"request_id":"req_011CVQWEXnv3LmnLi2Bg3sQV"}

Steps to reproduce:

1. Ask Claude to take a screenshot of any page using Chrome DevTools MCP
2. The screenshot is taken in PNG format (default)
3. Claude Code sends it to the API with media_type: "image/jpeg"
4. API rejects it due to mismatch

Despite issue #11936 claiming this was fixed in v2.0.50, the bug persists. The root cause appears to be Claude Code hardcoding JPEG media type
regardless of actual image format returned by MCP tools.

Can confirm this issue still exists in Claude Code v2.0.50 (latest) with Chrome DevTools MCP on Linux. Environment: Claude Code version: 2.0.50 Platform: Linux (6.14.0-35-generic) MCP: Chrome DevTools (built-in) Tool: mcp__chrome-devtools__take_screenshot Error: API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.1.content.6.image.source.base64.data: Image does not match the provided media type image/jpeg"},"request_id":"req_011CVQWEXnv3LmnLi2Bg3sQV"} Steps to reproduce: 1. Ask Claude to take a screenshot of any page using Chrome DevTools MCP 2. The screenshot is taken in PNG format (default) 3. Claude Code sends it to the API with media_type: "image/jpeg" 4. API rejects it due to mismatch Despite issue #11936 claiming this was fixed in v2.0.50, the bug persists. The root cause appears to be Claude Code hardcoding JPEG media type regardless of actual image format returned by MCP tools.

Currently, there is a temporary solution: you can manually write a mcp tool that calls the JPG image from Figma, and prohibit MCP from using the get_screenshot tool to access Figma. You can refer to the following code:

async getImageData(
    fileKey: string,
    nodeId: string,
  ): Promise<string> {
    const images = await this.request<GetImagesResponse>(
      `/images/${fileKey}?ids=${nodeId}&scale=2&format=jpg`,
    ).then(({ images = {} }) => images)
    let image = ''

    for (const key in images) {
      image = images[key] as string
    }

    return image
  }

Can confirm this issue still exists in Claude Code v2.0.50 (latest) with Chrome DevTools MCP on Linux. Environment: Claude Code version: 2.0.50 Platform: Linux (6.14.0-35-generic) MCP: Chrome DevTools (built-in) Tool: mcp__chrome-devtools__take_screenshot Error: API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.1.content.6.image.source.base64.data: Image does not match the provided media type image/jpeg"},"request_id":"req_011CVQWEXnv3LmnLi2Bg3sQV"} Steps to reproduce: 1. Ask Claude to take a screenshot of any page using Chrome DevTools MCP 2. The screenshot is taken in PNG format (default) 3. Claude Code sends it to the API with media_type: "image/jpeg" 4. API rejects it due to mismatch Despite issue #11936 claiming this was fixed in v2.0.50, the bug persists. The root cause appears to be Claude Code hardcoding JPEG media type regardless of actual image format returned by MCP tools.

I apologize for the late response. I had been using a downgraded version (2.0.30) to avoid errors, but I've since updated alongside the Opus 4.5 release and am now on 2.0.57. I've been using Chrome DevTools MCP continuously since then and haven't experienced any errors.

Having this issue on 2.0.59 too.

API Error: 400
f"type": "error", "error": {"type":"invalid_request_error","
message": "messages. 13. content.5. image.source.base64.data:
Image does not match the provided media type
image/jpeg"}, "request_id": "req_011CVo58ve6dbpwnDwL46v56"}

Add Mobile-MCP to the list, i guess every mcp using screenshots/images is having the issue.

Playwright-MCP, Chrome DevTools MCP, Mobile-MCP...

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

I can no longer upload ANY images to Claude code WEB. I can make them myself of any type and it complains about WEBP..so theres something in the web app changing them

API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.0.content.0.image.source.base64.data: Image does not match the provided media type image/webp"},"request_id":"req_011CXE91vbTKZNYYsmw8kjz5"}

this is the error I get if I upload png or jpeg images. worked occasionally till this week, now I cant EVER upload an image.

Same error triggered via iPhone clipboard paste

I can reproduce this with a different trigger — pasting a screenshot directly copied from an iPhone.

Error:

API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.4.content.1.image.source.base64.data: Image does not match the provided media type image/png"}}
Steps to reproduce:

Take a screenshot on iPhone
Copy/share it to Mac clipboard (e.g., via AirDrop or PastePal)
Paste the image into Claude Code chat
Root cause (suspected): Claude Code likely assumes clipboard images are PNG and hardcodes media_type: "image/png", but iOS clipboard images may be in JPEG or HEIC format internally.

This is a different trigger from the MCP screenshot tools discussed above, but the same underlying bug — media_type is declared without validating against the actual image bytes.

Thank you for your report — we are currently in the process of triaging MCP-related issues and this one appears to describe the same problem as #11975. To keep the discussion and any fix in one place, we're consolidating into that issue and closing this one. If you have logs, repro steps, or environment details that aren't already covered in #11975, please add them there — it'll help us track this down faster.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.