Image Tokens: How Pictures Are Priced

An image costs input tokens, and the count is not proportional to file size, or to what you paid for the JPEG, or to anything you can see. It is a function of dimensions, published by each provider, and it is usually quadratic in the long edge. Knowing the function is worth money, because the cheapest optimisation available is resizing before upload.

Everything below is as of August 2026 and comes from each provider’s own vision or pricing documentation. Check the current page before you commit a number to a spreadsheet: the formulas are more stable than the rates, but neither is a constant of nature, and model families within one vendor have differed from each other.

Why an image has a token count at all

Because it literally becomes tokens. The image is cut into patches, encoded, and inserted into the sequence — so it occupies context and costs prefill compute exactly as text does. The provider’s formula is not a billing abstraction invented for invoicing; it is an approximation of how many vectors their encoder will actually produce for an image of that shape.

Which is why file size is irrelevant and dimensions are everything. A 40 kB heavily-compressed JPEG and a 4 MB PNG of the same scene at the same dimensions cost identically, because both are decoded to the same pixel grid before anything else happens. People routinely optimise the wrong number here — compressing harder saves upload bandwidth and nothing else. Resizing saves money. The one place file size does bite is the request limit: providers cap the encoded payload, typically in the region of 5 to 20 MB per image, and a base64-encoded body is about a third larger than the bytes it carries, which is a limit people hit while still well under what they thought the cap was.

The published formulas

Tile-and-add (OpenAI style)

OpenAI documents a two-step resize followed by a tile count. In high detail, the image is scaled to fit inside 2048 ×  2048, then scaled so the shortest side is 768 px, then divided into 512 × 512 tiles. The cost is a base token count plus a per-tile count — documented as 85 base and 170 per tile for the GPT-4o generation, with newer and smaller models applying their own multiplier to those figures. Low detail skips the tiling entirely and charges the base only.

Area over a constant (Anthropic style)

Anthropic publishes a formula rather than a tile count: approximately (width × height) / 750 tokens, with images whose long edge exceeds roughly 1568 px scaled down first. It is the same quadratic in a simpler dress — no tile boundaries to land badly on, which makes it the easiest of the three to predict.

Fixed-cost crops (Gemini style)

Google documents a threshold: an image whose dimensions are both at or under 384 px costs a flat 258 tokens. Anything larger is cropped into tiles and each tile costs that same 258. The consequence is a step function — an image just over the threshold costs several times one just under it.

Three images, run through each

Applying the formulas above as documented, ignoring the per-model multipliers:

A. avatar          256 x 256
B. photo          1024 x 1024
C. screenshot     2560 x 1440

tile-and-add, high detail
  A  short side 256 -> upscaled to 768 -> 768x768 -> 2x2 tiles
     85 + 4*170 = 765
  B  short side 1024 -> scaled to 768 -> 768x768 -> 2x2 tiles
     85 + 4*170 = 765
  C  fits in 2048 box -> 2048x1152 -> short side to 768 -> 1365x768
     ceil(1365/512)=3, ceil(768/512)=2 -> 6 tiles
     85 + 6*170 = 1105
  any, low detail                                    85

area / 750
  A  65536/750    = 87
  B  1048576/750  = 1398
  C  long edge over 1568 -> 1568x882 -> 1383/750 ... = 1844

fixed-cost crops
  A  both sides <= 384                              258
  B  tiled                            several x 258
  C  tiled                            many x 258

Two things jump out. The avatar is not cheap under a tile-and-add scheme — a small image gets upscaled to the minimum short side and is billed as if it were 768 × 768, which is why sending 40 tiny thumbnails is a genuinely bad idea there and nearly free under the area formula. And the difference between the full screenshot and the low-detail flag is more than an order of magnitude.

Resize before you send

If the provider is going to downscale your image anyway, doing it yourself first is free money and free latency — you also stop paying to upload pixels that are discarded on arrival.

from PIL import Image

MAX_EDGE = 1568   # match the provider's documented ceiling

def prepare(path):
    im = Image.open(path).convert("RGB")
    w, h = im.size
    if max(w, h) > MAX_EDGE:
        s = MAX_EDGE / max(w, h)
        im = im.resize((round(w * s), round(h * s)), Image.LANCZOS)
    return im

One caution: resize is exactly the step that destroys small text. Downscale a scanned invoice to the ceiling and the totals may stop being legible. Where the task depends on fine detail, crop the region of interest at native resolution instead of shrinking the whole page — a 600 × 200 crop of the line you need costs a fraction of the page and carries strictly more information about it.

What to actually watch

• Image tokens are input tokens. They are subject to the same input rate, and on most platforms the same prompt-caching rules, which matters when a fixed reference image appears in every request.
• Aspect ratio changes the bill under tiling. A panorama and a square of equal area do not cost the same, because tiles are counted per axis with a ceiling on each.
• Check the usage object, do not trust your arithmetic. Every provider returns actual prompt token counts in the response. Log them per request for a day before modelling a month.
• The multiplier is where surprises live. Small models often apply a factor to the base and per-tile numbers, so the cheap model is not always cheap per image even when it is cheap per word.
• A PDF is billed as pages, not as a file. Where an API accepts documents directly, each page is rendered and tokenised as an image. A 40-page report is 40 images, and the request that looked like one attachment is the largest prompt your application has ever sent.

One structural note that outlives every number above. Because image tokens are ordinary input tokens, an image that appears at a stable position in a stable prefix is cacheable in the same way a system prompt is — a reference diagram, a brand style sheet, a form template that accompanies every request. Put it at the front of the prompt and keep the bytes byte-identical, since caching keys on an exact prefix match and a re-encoded JPEG is a different prefix even when it looks the same. Getting that ordering right is worth more, on a high-volume pipeline, than any per-image resizing.