How Many Tokens Is an Image in the OpenAI API? Patch Math

An image costs the ceiling of its width divided by 32, times the ceiling of its height divided by 32, in patches. If that exceeds the model's patch budget the image is shrunk to fit and re-counted, and the final patch count is then multiplied by a per-model figure. A scanned US Letter page at 150 DPI works out to 2,080 patches on a full model, or 1,496 patches on GPT-5.4-mini and nano, which become about 2,424 and 3,680 tokens respectively after the multiplier.

That is the whole rule, but each of the three steps has a detail that trips people up. All of this was checked against OpenAI's own vision documentation on July 22, 2026.

Step one: count the patches

OpenAI covers the image with a grid of 32 by 32 pixel patches. A patch may extend past the image boundary, which is why both dimensions round up rather than down.

patches = ceil(width / 32) x ceil(height / 32)

A 1,024 by 1,024 image is 32 by 32, so 1,024 patches. A scanned letter page at 150 DPI is 1,275 by 1,650 pixels, which is 40 across and 52 down, so 2,080 patches.

Step two: shrink if it exceeds the budget

Each model has a patch budget, and they are not all the same. This is the part most write-ups get wrong, because for a long time a single number was quoted for everything.

On GPT-5.5 and GPT-5.6, an omitted detail parameter and detail set to auto both behave like original.

So our 2,080 patch letter page sits comfortably inside a full model's budget and is used as is. On mini or nano it breaks the 1,536 cap and has to be scaled down.

The scaling is two steps, and skipping the second one is the single most common error in every token calculator floating around. First the image is scaled proportionally so the patch count fits the budget. Then it is adjusted so the height lands on a whole patch boundary, and only then are the patches re-counted.

For our letter page, the proportional scale alone gives 1,095 by 1,418 pixels, which re-counts to 34 by 45, or 1,530 patches. Apply the height adjustment and it becomes 1,088 by 1,408 pixels, which is 34 by 44, or 1,496 patches.

You can verify that yourself against the worked example OpenAI publishes. The docs state that an 1,800 by 2,400 pixel image resolves to 1,452 patches on a 1,536 budget. A single proportional shrink returns 1,530 for that image, which is wrong. The two-step version returns 1,452 exactly. If your implementation cannot reproduce 1,452, it will not reproduce 1,496 either.

Step three: apply the model multiplier

The final patch count is multiplied by a per-model figure to get billable input tokens.

Note the last row honestly. OpenAI lists multipliers only for the mini and nano tier. There is no published multiplier for the full models, which most naturally means the patch count is the token count, but that is an inference rather than a documented rate, so it is worth flagging in any estimate you hand to someone else.

Running our letter page through: on GPT-5.4-mini, 1,496 patches times 1.62 is about 2,424 tokens. On GPT-5.4-nano, 1,496 times 2.46 is about 3,680 tokens. On a full model, 2,080 patches.

The counterintuitive result

Look at that pair again. Nano bills more image tokens for the same page than mini does, 3,680 against 2,424, despite being the cheaper model. The multiplier is doing the opposite of what its price position suggests.

Work through the money and the effect is clear. Nano lists at $0.20 per million input tokens and mini at $0.75, which looks like nano is 3.75 times cheaper. Multiply out the effective cost of a single image patch and nano is $0.492 per million against mini's $1.215, a ratio of only 2.47. The multiplier eats roughly a third of nano's advertised discount, and it does so only on image work.

If you sized a document pipeline off the headline token prices, this is where your estimate drifted. The full per-model cost breakdown, converted to dollars per 1,000 pages, is on the OpenAI OCR pricing reference.

The other thing the budget split means

There is a second consequence that has nothing to do with billing. A letter page is 2,080 patches of real detail. A full model receives all of it. Mini and nano receive a version compressed to 1,496 patches, which is 28 percent less of the page.

That is why sending higher resolution scans to a small model does not improve results. A 300 DPI page arrives at 2,550 by 3,300 pixels, gets counted at 8,320 patches, and is scaled straight back down to 1,496 before the model looks at it. You paid nothing extra and gained nothing. On a full model at original detail the same page fits inside the 10,000 patch budget and does keep its detail, which is a genuine reason to route dense documents upward rather than a pure accuracy hunch.

Anthropic has the same structure under a different name. Its standard resolution tier caps at 1,568 visual tokens against 4,784 on the high resolution tier, shrinking a letter page by 42 percent. Two vendors, independently, decided their cheap models would look at a smaller picture. The LLM OCR pricing pillar puts both side by side.

Estimating your own images

A short checklist for getting a number you can defend.

• Use the real pixel dimensions of your files, not the paper size. A PDF page rendered at 200 DPI is a different image from the same page at 150.
• Round both dimensions up to whole patches before multiplying. The rounding is not negligible on narrow images.
• Check the budget for the specific model you are calling, not a remembered figure. 1,536 and 2,500 are both correct, for different models.
• Do the height adjustment in the shrink step. Validate your implementation against the published 1,452 figure before trusting it.
• Apply the multiplier only where one is published.
• Then add the output tokens, which for transcription work are usually the larger half of the bill.

That last point is worth repeating, because it is where estimates go badly wrong rather than slightly wrong. Output is billed at six times the input rate across the lineup. On a full page transcription of roughly 750 output tokens, output ends up being 56 to 68 percent of the total. Counting image tokens perfectly and then forgetting the response leaves you off by a factor of two or more.

When the image is not a scanned page

The same math covers screenshots, photographs and charts, and the patch budget matters more for wide images than tall ones because of the rounding. It also applies to content you did not start with as a file at all. If your input is a web page rather than a document, rendering it to an image and paying patch tokens is usually the expensive path, and pulling the page down as clean structured text first costs a small fraction of the same content sent as pixels.

For documents, though, the image path is often the only one that preserves layout, and then the numbers above are what you are working with. If you would rather not model any of it, upload a document to DocuOCR and see the extracted fields directly. The per-page price there is fixed and the token accounting is somebody else's problem.