Why your screenshot shrinks, and how to control it

You know where the paperclip is. You upload screenshots, you get usable answers, and sometimes you don't. This is about exactly that "sometimes you don't". It's rarely chance and almost never the model. It comes down to a few mechanics that nobody explains, because they sound technical, even though in daily use they boil down to three habits.

This playbook assumes you already upload images and PDFs. It doesn't explain the how, it explains the why behind it, and what that means for the way you work. Ten steps, and afterwards you'll understand why a 4K screenshot works worse than a cropped detail.

Step 1, the model sees tiles, not pixels

An image isn't read pixel by pixel, it's broken into tiles of 28 by 28 pixels. Each tile is one visual token. The arithmetic is simple: width divided by 28, rounded up, times height divided by 28, rounded up.

So an image of 1000 by 1000 pixels comes out at 36 by 36, which is 1296 tokens. That's roughly as expensive as a page of dense prose. Images aren't a free attachment, they're a noticeable part of your context. Anyone who spreads twelve screenshots across a long conversation eventually notices that the AI is losing sight of the beginning.

Step 2, the two resolution tiers

Every model has an upper limit for the longest edge of an image. Anything above that gets scaled down before processing, keeping the aspect ratio.

The current models from 4.7 onwards, so the whole 5 generation as well, work with a longest edge of 2576 pixels and a maximum of 4784 visual tokens. Older models sit at 1568 pixels and 1568 tokens. That's a factor of roughly three.

One thing matters here: there are two limits at once, the edge and the token budget, and the downscaling follows whichever bites first. Which one that is depends on the tier. On the higher tier the two land almost exactly together at 16 to 9. On the older one the budget bites well before the edge does. So your 3840 by 2160 screenshot doesn't land at 1568 by 882 on an older model, which is what the edge rule alone would suggest, but at roughly 1456 by 819. That's the exact moment the small type in your error message turns to mush, and the model starts guessing instead of reading. The higher tier is active automatically, you don't have to switch anything on, but it also costs up to three times as many tokens.

Step 3, the cropping trick

The first two steps lead straight to the most important habit in this playbook: crop before you upload.

A 900 by 600 pixel crop with the error message razor-sharp in it beats a 4K full screen where the same message has become unreadable after downscaling. That feels wrong, because more image looks like more context. In practice it's the other way round: you're paying with tokens and with resolution for your desktop wallpaper, your taskbar and your browser tabs, and that resolution is missing from your actual content.

If you genuinely need both, upload both. The overview once, the sharp crop once. Two targeted images beat one overloaded one.

Step 4, format and compression

JPEG, PNG, GIF and WebP get processed. With animated images only the first frame is evaluated, the rest is dropped entirely. Anyone who uploads an animated GIF and then wonders about the answer has usually missed exactly that.

For compression there's a rule that gets broken a lot in daily use: repeatedly compressed images destroy small type. A JPEG that has already been through two messengers and a screenshot tool has artefacts that can turn a 3 into an 8. If text in the image is the main thing, use PNG. If it's about a scene or an object, JPEG is perfectly fine and saves transfer time.

Step 5, the hard upper limits

Three numbers you actually run into in the chat window: a maximum of 8000 by 8000 pixels per image, a maximum of 10 MB per image, and a maximum of 20 images per message on claude.ai.

Over the programming interface the limits are higher, where 100 or 600 images per request are possible depending on the context window. In practice the total size of the request stops you before that, which sits at 32 MB. Other providers have different values. The principle is the same everywhere, the specific numbers change more often than a playbook can keep up with, so when in doubt check the documentation of the provider you're using.

Step 6, image first, question second

The cheapest quality gain in the whole playbook. The models demonstrably work better when the image comes before the text. So attach first, then type the question.

Does the other order work too? Yes, and reasonably well at that. But when you have the choice, and in the chat window you always do, take the version that measurably runs better. It costs you exactly nothing.

Step 7, label multiple images

As soon as more than one image is involved, give each one a label before you attach it. So "Image 1:" and then the image, "Image 2:" and then the next one.

That lets you point unambiguously in the question and in every follow-up: "What is different in image 2 compared to image 1?" Without labels you end up at "the top one" and "the other one", and then you're guessing yourself what the answer referred to. The before-and-after comparison is one of the strongest use cases there is, and it lives on both sides being named.

One nice thing: older images stay available in the running conversation. You don't have to upload them again for a follow-up question.

Step 8, a PDF is a series of images

When you upload a PDF, every page gets converted into an image and the text of the page is extracted on top of that. The model gets both. That's exactly why it can interpret diagrams and table layouts instead of only reproducing raw text.

The limits follow from that. Every page costs roughly 1500 to 3000 tokens, depending on density. Password-protected or encrypted files don't get processed at all, unlock them beforehand. And a dense document with tiny type and lots of graphics fills your context long before any page-count limit kicks in. With a 200-page contract you therefore upload the relevant chapters, not the whole block.

Two small moves that pay off disproportionately: straighten crooked scans beforehand, rotated pages are one of the most reliable sources of error. And give page numbers the way they appear in the PDF viewer, not the way they're printed at the bottom of the paper.

Step 9, tables don't belong in there as an image

The most common expensive mistake. A screenshot of a table forces the model to read numbers visually, and reading out of narrow columns is where most of the mix-ups happen.

Plain text formats like CSV, TXT or Markdown can be handed over directly and arrive as numbers, not as a picture of numbers. Binary formats like XLSX or DOCX don't go through the interface directly, you export those as CSV or PDF beforehand. The detour via CSV is almost always the better one.

Rule of thumb: as soon as the numbers are meant to be calculated with, the file belongs in there as text. An image is only enough when it's about the layout, so "explain to me what this diagram is saying".

Step 10, the five documented limits

This is the section that saves you from embarrassing mistakes. All five are in the official documentation exactly like this, this isn't my assessment.

People in images don't get named, that's refused on principle. Counting is approximate, especially with lots of small objects, so never rely on a "how many are there" answer. Very small, blurry or rotated images under roughly 200 pixels reliably lead to invented answers. Medical cross-sectional images like CT or MRI are explicitly not a use case and don't replace a doctor's assessment.

And the most important point, because it directly contradicts the widespread gut feeling: the model cannot tell whether an image is itself AI-generated. If you ask, you'll get an answer, and it can simply be wrong. Never use this as an authenticity check. Anyone working in that direction is better served, and more honestly served, by Recognising and labelling AI content and, for the fraud case, by Protecting yourself from AI fraud.

What's next

Because images cost context and context is finite, Context and tokens belongs right next to this playbook. That's where you'll find why a long conversation with a lot of screenshots eventually gets sluggish.

And because a very convincing answer about an image can still be wrong, especially when reading numbers off diagrams, the routine from Fact-checking an AI answer is the fitting second step. What you should upload in principle and what you shouldn't is in Data protection, what am I allowed to enter. Screenshots are the trickiest case there, because there's often more at the edge of the picture than what you're looking at.

Where the info comes from

All the numbers on resolution tiers, visual tokens, formats and upper limits come from the official documentation on vision at https://docs.claude.com/en/docs/build-with-claude/vision. The details on page processing, tokens per page and CSV versus XLSX are at https://docs.claude.com/en/docs/build-with-claude/pdf-support. The five limits in step 10 are the ones documented there.

For ChatGPT and Gemini the same basic principles apply, so image before text, crop instead of full screen, tables as text instead of as an image. The specific upper limits differ and are in each provider's own documentation.