Published Build3 min read
Claude bills vision by pixel area, so compressing the image saves nothing
Anthropic's published formula for image tokens has no term for file size or format. Only downscaling and cropping change the invoice, and a documented ceiling quietly caps what any one image can cost.
Written for builders.See today for builders

What happened
- Anthropic's vision documentation gives the token estimate for an image as tokens ~= (width_px x height_px) / 750, a function of pixel dimensions rather than file size.
- Neither file size nor image format appears anywhere in the token formula.
- A 4 MB PNG and a 300 KB JPEG of the same 1200x800 scene cost the same number of tokens; compressing an image harder saves upload bandwidth but nothing on the bill, while resizing saves both.
- The 750 divisor approximates a patching step in which the image is cut into fixed-size patches; the total scales with area rather than with either edge, so doubling both edges quadruples the token count.
- A 640x480 screenshot is 307,200 pixels, giving 307,200 / 750 = 409.6, or about 410 tokens, and passes through unchanged.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
Anthropic's vision documentation prices an image as a function of its pixel dimensions: tokens are approximately width in pixels times height in pixels, divided by 750 [1]. File size does not appear in that expression, and neither does format [2], which means the first lever most teams reach for when an inference bill grows is wired to nothing.
A 4 MB PNG and a 300 KB JPEG of the same 1200x800 scene cost the same number of tokens [3]. Compressing harder saves upload bandwidth and saves nothing on the bill; resizing saves both [3]. The divisor is round because it approximates a patching step, and the total scales with area rather than with either edge [4]. The consequence worth internalising: doubling both edges quadruples the token count, so a "slightly bigger" screenshot is not slightly more expensive [4].
The worked numbers, as set out in a dev.to walkthrough of Anthropic's documentation. A 640x480 UI screenshot is 307,200 pixels, or about 410 tokens [5]. A 1200x800 web photo is 960,000 pixels, about 1,280 tokens [6]. A 4032x3024 phone photo is 12,192,768 pixels, which the raw formula puts at 16,257 tokens [7] and which you are not charged, because two documented limits intervene. If the long edge exceeds 1568 pixels, the image is scaled down before it reaches the model [8]. 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 [9], derived from 1,600 times 750 [10].
Applied to the phone photo, the first limit gives 1568x1176, which is still 2,458 tokens and above the ceiling [11]; a second reduction to about 1238x928 lands at roughly 1,530 tokens [12]. The exact output dimensions are Anthropic's choice, not yours, and those intermediate numbers are an illustration of the documented ceiling rather than a published table [13]. Net effect: the 12-megapixel upload ends up costing about a tenth of what its pixel count implies [14], and a 12-megapixel and a 2-megapixel photo of the same scene cost roughly the same [15]. What you lose is detail, discarded by a downscale that has no idea what you needed to see [16]. If the model has to read small text, crop to the region rather than sending the whole frame [17].
This reshapes document pipelines more than it looks. An A4 page scanned at 300 dpi is about 2480x3508 pixels [18]; sent whole, it costs the ceiling of about 1,600 tokens [19], which is roughly one seventh of what its area would otherwise imply [20], and the quadrant you actually care about arrives at a fraction of the resolution you scanned [19]. Below the ceiling the meter is honestly proportional: 640x480 really is a third of the cost of 1200x800, and there is no minimum charge that makes small crops pointless [21].
Two things to watch. Anthropic calls the formula an estimate; the billed figure is what comes back in usage.input_tokens, and the pre-flight figure is the count_tokens endpoint, which accepts image blocks [22]. And image handling is an area vendors revise, so re-check the limits before you build a budget on them [23].
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Anthropic's vision documentation gives the token estimate for an image as tokens ~= (width_px x height_px) / 750, a function of pixel dimensions rather than file size.
- [2]
Neither file size nor image format appears anywhere in the token formula.
- [3]
A 4 MB PNG and a 300 KB JPEG of the same 1200x800 scene cost the same number of tokens; compressing an image harder saves upload bandwidth but nothing on the bill, while resizing saves both.
- [4]
The 750 divisor approximates a patching step in which the image is cut into fixed-size patches; the total scales with area rather than with either edge, so doubling both edges quadruples the token count.
- [5]
A 640x480 screenshot is 307,200 pixels, giving 307,200 / 750 = 409.6, or about 410 tokens, and passes through unchanged.
- [6]
A 1200x800 web photo is 960,000 pixels, giving 960,000 / 750 = 1,280 tokens, and passes through unchanged.
Sources & coverage · 1 publisher
The reporting this story was synthesized from, earliest first. Every link goes to the original.
- dev.toMultigridAug 12Claude Vision: Image Size and Token Cost per Image
Cited in this coverage: dev.to, reporting Anthropic vision documentation
Cited in this coverage: dev.to

