{"slug": "claude-vision-image-size-and-token-cost-per-image", "title": "Claude Vision: Image Size and Token Cost per Image", "summary": "Anthropic's Claude vision API bills images based on pixel dimensions, not file size, with tokens estimated as width times height divided by 750. The company caps each image at roughly 1,600 tokens by scaling down large images, so a 12-megapixel photo costs about the same as a 2-megapixel one, but loses detail.", "body_md": "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.\n\nAnthropic’s vision documentation gives the estimate as width in pixels multiplied by height in pixels, divided by 750:\n\n```\ntokens ≈ (width_px × height_px) / 750\n```\n\nFile 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.\n\nThe 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.\n\nAnthropic describes this as an estimate, not an invoice. The number that is billed is the one that comes back in `usage.input_tokens`\n\n, and the number you can check in advance is the one from [the count_tokens endpoint](https://multigrid.ai/learn/claude-count-tokens-endpoint), which accepts image blocks. Use the formula for capacity planning and the endpoint for anything that has to be right.\n\nFormula and limits as documented by Anthropic on its vision page at the time of writing. See [Anthropic’s vision documentation](https://docs.anthropic.com/en/docs/build-with-claude/vision). Image handling is an area vendors revise; re-check before you build a budget on it.\n\nThree sizes you actually encounter: a small UI screenshot, a web-resolution photograph, and a photo straight off a phone camera.\n\n```\nA. 640 × 480 screenshot\n   640 × 480          =   307,200 px\n   307,200 / 750      =       409.6  →  ~410 tokens\n\nB. 1200 × 800 web photo\n   1200 × 800         =   960,000 px\n   960,000 / 750      =     1,280    →  ~1,280 tokens\n\nC. 4032 × 3024 phone photo (12 MP, 4:3)\n   4032 × 3024        = 12,192,768 px\n   12,192,768 / 750   =    16,257    →  not what you are charged;\n                                        see the resize ceiling below\n```\n\nA 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.\n\nAnthropic 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.\n\nApply both to image C. The first limit scales the long edge to 1568, preserving the 4:3 aspect ratio:\n\n```\n1568 / 4032        = 0.3889 scale factor\n3024 × 0.3889      = 1176\n1568 × 1176        = 1,843,968 px\n1,843,968 / 750    =     2,458 tokens   →  still above the ~1,600 ceiling\n```\n\nSo a second reduction applies, down to about 1.15 megapixels. At 4:3 that is roughly 1238 × 928:\n\n```\n1238 × 928         = 1,148,864 px\n1,148,864 / 750    =     1,531.8  →  ~1,530 tokens\n\nAssumptions labelled: 1.15 MP is derived from the documented\n~1,600-token ceiling (1,600 × 750 = 1,200,000 px), and the exact\noutput dimensions Anthropic picks are its choice, not yours. The\nceiling is the documented figure; the intermediate dimensions here\nare a worked illustration of it.\n```\n\nThe 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.\n\nThe 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.\n\nThis 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`\n\n, 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.\n\nThe 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 separately. Send them separately.\n\nImage tokens are input tokens and are billed at the model’s input rate. Taking a Sonnet-class input price of $3 per million tokens, which is the figure Anthropic has published on its pricing page for that tier at the time of writing:\n\n```\nAssumption: $3.00 per 1,000,000 input tokens (Sonnet-class).\n\nA.   410 tokens × $3 / 1,000,000  =  $0.00123 per image\nB. 1,280 tokens × $3 / 1,000,000  =  $0.00384 per image\nC. 1,530 tokens × $3 / 1,000,000  =  $0.00459 per image\n\nAt the ceiling, 1,000 images ≈ 1,530,000 tokens ≈ $4.59\nplus whatever text accompanies them.\n```\n\nThat last line is the one to hold on to. A vision pipeline processing a thousand photos a day costs a few dollars a day in image tokens, and the surrounding prompt — instructions, few-shot examples, tool definitions — is frequently the larger half of the bill. If you are optimising a vision workload and you have not counted the system prompt, you are probably optimising the wrong thing.\n\nPrices change and tiers differ per model. Check [Anthropic’s pricing page](https://docs.anthropic.com/en/docs/about-claude/pricing) for the current rate for the specific model id you are calling, not for its family.\n\nThe images-per-request cap deserves a moment of planning rather than a retry loop, because hitting it is a validation error and not a throttle. If you are processing a fifty-page scan, the batch size is decided by that cap and by the context window together, and the window is usually the tighter of the two: fifty pages at the ceiling is 80,000 tokens before you have written a prompt. Work out the batch size from the arithmetic once, at design time, rather than discovering it as a 400 in production.\n\nTo settle any of this for a specific image, send the exact message array to `/v1/messages/count_tokens`\n\ninstead of `/v1/messages`\n\n. It accepts image content blocks and returns the input token count the real call would be billed for, at no charge. That is a better answer than any formula, and it takes one request.\n\nOne last thing the formula cannot tell you, and which is the actual cost driver in most vision applications: images are input, and input is the cheap half. A pipeline that sends one 1,530-token image and receives a 900-token structured description is paying more for the description than for the picture at typical output rates. Optimising image size is worth doing and it is not where the money is. Ask for less output.", "url": "https://wpnews.pro/news/claude-vision-image-size-and-token-cost-per-image", "canonical_source": "https://dev.to/multigrid/claude-vision-image-size-and-token-cost-per-image-5gln", "published_at": "2026-08-12 22:21:14+00:00", "updated_at": "2026-08-12 22:46:13.914729+00:00", "lang": "en", "topics": ["large-language-models", "ai-products", "ai-infrastructure"], "entities": ["Anthropic", "Claude"], "alternates": {"html": "https://wpnews.pro/news/claude-vision-image-size-and-token-cost-per-image", "markdown": "https://wpnews.pro/news/claude-vision-image-size-and-token-cost-per-image.md", "text": "https://wpnews.pro/news/claude-vision-image-size-and-token-cost-per-image.txt", "jsonld": "https://wpnews.pro/news/claude-vision-image-size-and-token-cost-per-image.jsonld"}}