Claude Vision: Image Size and Token Cost per Image

The formula

An image sent to Claude is billed as input tokens, and the count is a function of its pixel dimensions rather than its file size. Anthropic publishes the arithmetic, which means you can price a vision workload before you send a single request.

The documented formula Anthropic’s vision documentation gives the estimate as width in pixels multiplied by height in pixels, divided by 750:

tokens ≈ (width_px × height_px) / 750

File size does not appear anywhere in that expression, and neither does format. A 4 MB PNG and a 300 KB JPEG of the same 1200×800 scene cost the same number of tokens. Compressing an image harder saves upload bandwidth and saves you nothing at all on the bill; resizing it saves both.

The reason the divisor is a round number is that it is an approximation of a patching step. The image is cut into fixed-size patches, each patch becomes a small number of embedding positions, and the total scales with area rather than with either edge. Doubling both edges quadruples the token count, which is the single most useful consequence of the formula: a “slightly bigger” screenshot is not slightly more expensive.

Anthropic describes this as an estimate, not an invoice. The number that is billed is the one that comes back in usage.input_tokens, and the number you can check in advance is the one from the count_tokens endpoint, which accepts image blocks. Use the formula for capacity planning and the endpoint for anything that has to be right.

Formula and limits as documented by Anthropic on its vision page at the time of writing. See Anthropic’s vision documentation. Image handling is an area vendors revise; re-check before you build a budget on it.

Three real images, worked

Three sizes you actually encounter: a small UI screenshot, a web-resolution photograph, and a photo straight off a phone camera.

• A. 640 × 480 screenshot
  640 × 480 = 307,200 px
307,200 / 750 = 409.6 → ~410 tokens

• B. 1200 × 800 web photo
  1200 × 800 = 960,000 px
960,000 / 750 = 1,280 → ~1,280 tokens

• C. 4032 × 3024 phone photo (12 MP, 4:3)
  4032 × 3024 = 12,192,768 px
12,192,768 / 750 = 16,257 → not what you are charged; see the resize ceiling below

A and B pass through unchanged: both are under the long-edge limit and both land under the per-image token ceiling. C does not, and that is the case worth understanding, because it is the one most real uploads fall into.

The resize ceiling

Anthropic documents two limits that together cap what one image can cost. If the long edge exceeds 1568 pixels, the image is scaled down before it reaches the model. And an image is scaled so that it does not exceed roughly 1,600 tokens, which working the formula backwards is about 1.15 megapixels.

Apply both to image C.

The first limit scales the long edge to 1568, preserving the 4:3 aspect ratio:

1568 / 4032 = 0.3889 scale factor
3024 × 0.3889 = 1176
1568 × 1176 = 1,843,968 px
1,843,968 / 750 = 2,458 tokens → still above the ~1,600 ceiling

So a second reduction applies, down to about 1.15 megapixels. At 4:3 that is roughly 1238 × 928:

1238 × 928 = 1,148,864 px
1,148,864 / 750 = 1,531.8 → ~1,530 tokens

Assumptions labelled: 1.15 MP is derived from the documented ~1,600-token ceiling (1,600 × 750 = 1,200,000 px), and the exact output dimensions Anthropic picks are its choice, not yours. The ceiling is the documented figure; the intermediate dimensions here are a worked illustration of it.

The practical reading: no single image costs much more than about 1,600 tokens, whatever you upload. A 12-megapixel photo and a 2-megapixel photo of the same scene cost roughly the same, because both are flattened to the same ceiling - and the 12-megapixel one costs you the upload time and, more importantly, the detail.

Downscaling happens without regard for what you needed to see. If the model has to read small text in a photograph, crop to the region rather than sending the whole frame and hoping.

The corollary for small images is the mirror of it. Below the ceiling you pay in proportion to area, so 640×480 really is a third of the cost of 1200×800. There is no minimum charge that makes small images pointless.

This changes the shape of a document-reading pipeline more than it first appears. Suppose you have an A4 page scanned at 300 dpi, which is about 2480×3508 pixels, and the thing you need off it is a total in the bottom right quadrant. Sending the whole page costs the ceiling, about 1,600 tokens, and the model receives that quadrant at roughly a quarter of the resolution the downscale left, which is a fraction of what you scanned. Sending a 900×600 crop of the quadrant costs 540,000 / 750, about 720 tokens, and the model receives the region at full scanned resolution. You paid less than half and gave the model several times the detail.

Every rule of thumb that says “send the whole page, the model will find it” is inherited from tools where resolution was not the binding constraint.

The same reasoning argues against the opposite instinct - stitching several small images into one contact sheet to save on per-image overhead. There is no meaningful per-image overhead to save. Area is area, and a tiled composite of nine screenshots is downscaled as one image, so each tile ends up at a ninth of the resolution it would have had on its own, for the same total token cost as sending them