How many tokens
is your image, really?
The token bill for an image is decided by its pixel dimensions, not by its file size. We measured one 4.6 MB PNG at seven compression targets and the result is the opposite of what most people expect.
Short answer: under the documented high-detail rule an image costs 85 tokens plus 170 per 512 × 512 tile. We compressed one 4,642,935-byte PNG to an 18,800-byte file and the token count did not move: 765 tokens either way, because both outputs still cover four tiles. Tokens only fall below a tile boundary — under 512 pixels on a side is one tile, and detail: low is a flat 85.
Written by the Tool Pantry team on 22 October 2026. The token rule is the published high-detail rule for the GPT-4o, 4.1 and 4.5 families; newer models use patch-based budgets, so treat the figures as that rule rather than a universal constant. The byte and pixel numbers are our own measurements on synthetic fixtures from 15 October 2026, kept in samples/compression/2026-10-15/, and the pixel reductions were forced by the target size rather than chosen for quality.
Bytes and tokens are two different axes
This is the part that surprises people, so it is worth being precise. When you send a file to a model, two separate things are counted:
- Bytes — how long the upload takes, how much disk it occupies, what a file-size limit will stop.
- Tokens — what the model is billed or billed-by, and what fills the context window.
For an image, the token count is driven by its pixel dimensions, not by how many bytes the file happens to be. So compressing a photo to a tenth of its size usually saves you nothing in tokens. It saves you upload time, and it saves the bytes that a tool caches, stores or re-reads.
The rule, as documented
For the GPT-4o, 4.1 and 4.5 families, a vision model with detail: high is processed like this: the image is scaled so its shortest side is 768 pixels, it is covered with 512 × 512 tiles, and the cost is 85 tokens plus 170 per tile. With detail: low there are no tiles at all and the cost is a flat 85 tokens whatever the size.
Newer models use patch-based tokenisation with different budgets, so treat the figures below as the high-detail rule for those families rather than a universal constant. OpenAI publishes an image cost calculator for the current models, and the arithmetic in this guide is the published tile rule applied to our own measured files.
What our own measurements showed
We ran one 4,642,935-byte PNG at 1600 × 1200 through the local compressors at every target size, then worked out the token cost of each output under that rule. The results are the interesting part:
| Target | Output size | Output pixels | Tokens (high detail) |
|---|---|---|---|
| 20 KB | 18,800 B | 951 × 713 | 765 |
| 50 KB | 49,465 B | 1360 × 1020 | 765 |
| 50 KB (WebP) | 49,126 B | 1032 × 774 | 765 |
| 100 KB | 98,489 B | 1600 × 1200 | 1,105 |
| 500 KB | 497,363 B | 1600 × 1200 | 1,105 |
| 2 MB | 1,312,441 B | 1600 × 1200 | 1,105 |
| 300 × 400 exactly | 38,306 B | 300 × 400 | 255 |
Read the middle of that table again. A 4.64 MB file and an 18.8 KB file, and the 20 KB one costs the same 765 tokens as the 49 KB one. The compression worked; the token bill did not move, because both outputs still cover four tiles.
The cliff is at 512 pixels, not at 100 KB
Tokens only fall when an output drops below a tile boundary. For a square image:
| Side length | Tiles | Tokens |
|---|---|---|
| 1600 | 3 × 3 | 1,445 |
| 1200 | 3 × 2 | 1,105 |
| 1000 | 2 × 2 | 765 |
| 768 | 2 × 2 | 765 |
| 512 | 1 × 1 | 255 |
| 300 | 1 × 1 | 255 |
Below 512 pixels on a side, the image collapses from four tiles to one and the cost falls from 765 to 255 tokens — a third of the price. At detail: low it is 85 whatever the size, which is a third of the cheapest picture above.
That is the real lever. Not "make the file smaller", but "make it fewer pixels, or ask for the low-detail path". Our target-size compressors will reduce dimensions when quality alone cannot meet the limit, and they tell you when they did — the 20 KB row above is 951 × 713 for exactly that reason.
The PDF trap
Here is the case where the obvious tool makes things worse. Compressing a PDF works by rasterising each page: the text becomes a picture of text. For a human reader that is often fine. For a model it is strictly worse — a page of searchable characters turns into a page of pixels, and the tokens go up, not down.
So for a PDF going into a model, the useful moves are the opposite of the ones for a photo:
- Extract the text with the PDF to text converter. A text page is about a quarter of the tokens of the same page as an image, and it stays searchable and quotable.
- Cut the page count rather than shrinking the pages. The page deleter and the splitter do that, and the saving is exact.
- Only rasterise when the page is a scan anyway — a page of handwriting has no text layer to lose.
Our own measurement of the same effect: a scanned PDF of 2,198,704 bytes became 410,435 bytes after compression, and every page of it is now an image. If the consumer of that file is a person, that is a good trade. If it is a model, it is the wrong one.
What to actually do
- Decide who is reading it. A person, or a model. The two answers are different, and the PDF case is where they diverge most.
- For a model, count tiles, not kilobytes. The image info tool gives you the dimensions, and the DPI calculator tells you what a print size would need. Under 512 pixels on a side is one tile; that is the line that matters.
- Compress for the transfer, not for the bill. A 4.6 MB upload on a slow connection is a wait; the same file at 49 KB is not. If the tool you are sending through has a file-size limit, that is where compression pays.
- Remember base64. Many clients encode an attachment as base64 before sending, which adds a third again: 4.6 MB becomes about 6.2 MB on the wire.
- Count the text, and cut it. For text, tokens are about a quarter of the characters, so shortening the text is the only real saving. The token counter gives exact counts for the common encodings, and the LLM token calculator turns a price into a per-request cost.
How many tokens is an image?
Under the documented high-detail rule for the GPT-4o, 4.1 and 4.5 families: the image is scaled so its shortest side is 768 pixels, covered with 512 by 512 tiles, and costs 85 tokens plus 170 per tile. A 1000 by 1000 image is four tiles, so 765 tokens. A 512 by 512 image is one tile, so 255. With detail: low it is a flat 85 tokens whatever the size. Newer models use different budgets, so check the provider's own calculator for the model you use.
Does compressing an image save tokens?
Usually not. Tokens are driven by pixel dimensions, not file size, so the same picture at 4.6 MB and at 18.8 KB cost the same 765 tokens in our measurements. Compression saves upload time and storage. To save tokens you have to reduce the pixels below a 512-pixel boundary, or use the low-detail path.
Should I compress a PDF before sending it to a model?
No, not if the PDF has text. Compressing rasterises the pages, so searchable characters become pixels and the token cost goes up. Extract the text instead, or cut the page count. Compression is the right move when the consumer is a person.
What is the cheapest way to send an image to a model?
Ask for the low-detail path, which is a flat 85 tokens. If you need the detail, keep the image under 512 pixels on a side for 255 tokens, or at most 1024 for 765. The image info tool tells you the dimensions of what you are about to send.
Do the file size limits still matter?
Yes, for the transfer rather than the bill. A portal with a 5 MB limit will refuse a 6 MB file regardless of how few tokens it is worth, and a large upload is a long wait on a slow connection. The file size limits guide has the numbers for the common services.