`--screenshotMaxWidth` returns images at twice the bound on a HiDPI display

[thomasbachem]

Description of the bug

--screenshotMaxWidth caps the image before the device scale factor is applied, so on a 2x display the returned screenshot is twice the requested width. Asking for 800 gives back 1600, four times the area.

That matters most where the flag came from: #1823 added it to keep screenshots under the 8000 pixel limit behind #879, and a cap picked to stay under that would still exceed it by the same factor.

The overshoot is also what gets billed. Anthropic prices an image at ceil(width/28) * ceil(height/28) visual tokens, so the 800x433 the flag should return costs 464 and the 1600x865 it does return costs 1798 – 3.9x on every capture, and still over 3x on a model whose long edge cap downscales the wider one.

Reproduction

Start Chrome with a given scale factor and connect to it:

"Google Chrome for Testing" --remote-debugging-port=9333 --headless=new \
  --window-size=1400,900 --force-device-scale-factor=2 https://example.com/

npx chrome-devtools-mcp@1.7.0 --browserUrl http://localhost:9333 --screenshotMaxWidth 800

Then call take_screenshot and read the PNG header. The bound holds exactly at a scale factor of 1 and is out by the factor above it:

DPR 1    no bound 1400x757     --screenshotMaxWidth 800 ->   800x433
DPR 2    no bound 2800x1514    --screenshotMaxWidth 800 ->  1600x865

Expectation

An image no wider than the requested maximum, since the flag is there to bound what reaches the model.

MCP configuration

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@1.7.0", "--browserUrl", "http://localhost:9333", "--screenshotMaxWidth", "800"]
    }
  }
}

Chrome DevTools MCP version

1.7.0

Chrome version

151.0.7922.71 (Chrome for Testing)

Coding agent version

Claude Code 2.1.92

Model version

Claude Opus 5

Node version

v24.19.0

Operating system

macOS 26.5.1

[bickov]

The DPR double is a clear bug, but the 8000px target in #879 may be the wrong bound to fix against.

8000 is the hard API reject. What actually determines whether the model can read the screenshot is the long-edge cap applied before inference: 2576px on Claude 4.7 and later, 1568px below that. So an 800px bound that correctly returns 800px still lands well inside a limit nobody is near, while a full-page capture with a bounded width can still be 15,000px tall and blow past 8000 on the other axis.

Bounding the long edge rather than the width would fix both this and that case. Measurements here if useful: https://slimsnap.ai/blog/screenshot-downscaling

[thomasbachem]

Whichever bound is the right one to aim at, the image still exceeds it. The unit is wrong here rather than the axis. The bound is compared in CSS pixels and the image comes back in device pixels, so a long edge bound of 800 overshoots on a 2x display exactly the way --screenshotMaxWidth 800 does.

There is already a flag for the other axis. --screenshotMaxHeight shipped with the width one, and computeDownscaleClip() takes the smaller of the two scales, so both set to the same value bounds the long edge, with the same factor on top.

[bickov]

@thomasbachem , fair, the unit is the bug, my axis point was beside it. Missed that --screenshotMaxHeight shipped alongside the width one, so both at the same value already does it.

Only thing left from me is what number to put there. 800 is arbitrary. Past 2576 on Claude 4.7+ and 1568 below, extra pixels don't buy anything, so that's probably the value worth suggesting.

[thomasbachem]

Those cap numbers are right, but the catch is below them. Pixels are still billed by area, so on the repro above an 800 bound is 464 visual tokens and a 2576 one is 4600.

The cap is a ceiling rather than a target, and which number is right depends on what the agent has to read. That is probably separate from this bug.