Claude prices an image the same way it prices text — in tokens — but the formula behind that price is rarely spelled out end to end. This article does exactly that: the formula, a worked example on a real screen, and a second worked example measured on an actual test screenshot, so you can estimate any image's cost yourself before you paste it into a coding agent. This is a companion piece to how many tokens a screenshot actually costs your agent, which covers why that cost matters for a coding workflow; this one stays narrowly on the math.
Updated July 2026.
What is the image token formula Claude uses?
Claude's high-resolution tier prices an image at approximately its width in pixels multiplied by its height in pixels, divided by 750. That raw division is then adjusted downward by Anthropic's 28-pixel patch-tiling model, which can't count partial patches — so the real, tokenized cost typically lands a few percent below what the raw formula alone predicts (Source: Anthropic, 2026).
Here's the formula on a screen everyone has: 1920×1080.
1,920 × 1,080 = 2,073,600 pixels
2,073,600 ÷ 750 = 2,764.8 tokens (raw formula)
The raw math says roughly 2,765 tokens. The actual, patch-tiled cost for a 1920×1080 image is 2,691 tokens (calculated) — about 2.7% below the raw division, because the tiling model rounds the image down to whole 28-pixel patches rather than charging for fractional ones.
Now the same formula on a real file, not a round number. A test screenshot captured on an M-series Mac at 1288×811 pixels:
1,288 × 811 = 1,044,968 pixels
1,044,968 ÷ 750 = 1,393.3 tokens (raw formula)
The raw math predicts about 1,393 tokens. The measured cost, read directly off the actual API usage for that file, was 1,334 tokens — about 4.3% below the raw prediction, the same patch-rounding effect showing up on a second, independently sized image. That consistent gap between "raw formula" and "real cost" is the whole point of showing two examples instead of one: it's not a rounding fluke on a single image, it's how the tiling model behaves.
Does image resolution change how many tokens an image costs?
Yes, directly and proportionally to total pixel count. Because the formula is width times height, resolution is the only input that matters — a sharper, larger capture of the same screen costs more tokens even though nothing about the underlying content changed. Two screenshots of the identical window at different zoom or Retina scaling can carry meaningfully different token bills.
This is easy to miss because resolution feels like a display setting, not a cost lever. A screen at 2x Retina scaling captured at native resolution can be 4x the pixel count — and therefore roughly 4x the tokens — of the same window captured at 1x, even though a human looking at either image sees the same content at the same apparent size.
Why do bigger screenshots cost more tokens than smaller ones?
Because the formula scales with area (width × height), not with either dimension in isolation. Doubling both width and height doesn't double the token cost — it roughly quadruples it, since area grows as the square of a linear scale factor. A screenshot that looks "twice as big" on screen can be four times as expensive to send.
This is the mechanism behind why cropping works so well as a cost lever, and why a full-page screenshot of a long document is disproportionately expensive compared to a screenshot of just the visible viewport.
Is there a token cap per image?
Yes, in effect. Anthropic resizes very large source images before applying the width-times-height-divided-by-750 formula, which keeps cost from climbing without limit as camera or display resolution increases. The precise resize thresholds aren't published with enough specificity to quote a number here — treat the formula above as the reliable estimate for anything at or under a standard 1080p capture, which covers the overwhelming majority of developer screenshots.
What this means in practice is that a 4K or 5K Retina screenshot doesn't cost proportionally more than its raw pixel count would suggest — the resize step catches it first. But a standard 1080p or smaller capture, which is what most developers are actually pasting into a chat window or a coding agent, sees the formula applied close to directly. The cap matters for exotic cases; the formula matters for the screenshot you're about to take right now.
How does Claude's high-resolution image tier work?
The high-resolution tier is what applies the width × height ÷ 750 formula in the first place, then tiles the result into 28-pixel-square patches for the actual token count. Patch tiling is why the two worked examples above (1920×1080 and 1288×811) both measured slightly under their raw formula prediction — the model can't bill for a partial patch, so it rounds down at the edges of the image.
Practically, this means the formula is a very good estimate but not an exact one. Budget a few percent of headroom above the raw division when you're sizing a token budget, and use a measured number instead of a calculated one whenever you actually have one, per the same measured-vs-calculated discipline this article follows throughout.
It also explains a small, easy-to-miss quirk: two screenshots with the same total pixel count but different aspect ratios (a wide, short capture versus a narrow, tall one) won't always tokenize to exactly the same count, because they tile into 28-pixel patches differently at the edges. The effect is small — a few tokens, not a few hundred — but it's the reason "width times height divided by 750" is described here as an approximation rather than an exact formula.
How do I estimate token cost before sending an image?
You can do the whole calculation by hand in three steps, no tools required:
- Multiply the image's width in pixels by its height in pixels.
- Divide that number by 750.
- Subtract 2-4% to account for patch-tiling rounding, based on the gap observed in both worked examples above.
For a fast mental shortcut with no arithmetic at all: a full-screen 1080p capture costs roughly 2,700 tokens. Scale up or down from that baseline by eye — a half-screen crop is roughly half that, a quarter-screen crop roughly a quarter.
Comparison: token cost by image dimension
| Image | Dimensions | Pixel count | Token cost | Type |
|---|---|---|---|---|
| 1080p full screen | 1920×1080 | 2,073,600 | 2,691 | Calculated (Anthropic formula, patch-tiled) |
| Real test screenshot | 1288×811 | 1,044,968 | 1,334 | Measured (M-series Mac, actual API usage) |
| Phone screenshot | 1170×2532 | 2,962,440 | ~3,950 | Calculated (raw formula estimate) |
| Cropped detail view | 800×600 | 480,000 | ~640 | Calculated (raw formula estimate) |
The two rows in the middle of the table are the load-bearing ones: one calculated straight from Anthropic's published formula, one measured on a real file. They agree with each other to within the margin patch tiling accounts for, which is what makes the formula usable as an estimation tool rather than just a theoretical curiosity. The phone-screenshot and cropped-detail rows use the same raw formula without a patch-tiling adjustment, so treat them as estimates rather than measured figures.
How can I shrink a screenshot's token cost?
Given that cost scales with pixel area, a few habits go a long way:
- Crop before pasting. Send only the region that matters — a 800×600 crop costs roughly 640 tokens versus roughly 2,691 for a full 1080p screen, a reduction of about 76%.
- Lower the capture resolution. If your tool lets you capture at 1x instead of 2x/Retina scaling, you cut the pixel count — and the token cost — by roughly 75% for the same visible content.
- Send text instead of pixels where you can. A stack trace, an error string, or a line number is often cheaper and more precise as plain text than as a screenshot of a terminal window.
- Narrate instead of screenshotting when you're not just showing an error. A typical spoken review transcript runs about 150 tokens (measured) — cheaper than nearly any cropped image, and it carries what you meant, not just what was visible. That's the case made in full in why that math gets even worse for video, which covers what happens once you multiply this same per-frame formula across a screen recording instead of a single still.
The bottom line
The formula is simple — width times height divided by 750, high-resolution tier, patch-tiled down a few percent — but its consequences aren't. A full 1080p screenshot costs about 2,691 tokens whether it shows a single button or an entire dashboard, because the formula only sees pixels, not meaning. Cropping, downscaling, and narrating instead of capturing are the three real levers a developer has to bring that number down before it eats into an agent's context window.