Explain a screenshot, photo or error message
Photograph an error box, a form or a whiteboard and ask an AI to read it. Which images work, which quietly fail, and how to phrase the question.
Your printer stops mid-job and drops a grey box on the screen: Error 0x0000011b, one button, marked OK. You photograph it with your phone, drop the photo into a chat and type three words. What is this. An answer comes back in seconds, fluent and specific, naming a Windows print spooler update from a few years ago and telling you which one to remove.
It might be right. The uncomfortable part is that you cannot tell from the answer itself, and what decided it had more to do with your photo and your three words than with which model you picked.
Reading pictures is one of the most common things people do in an AI chat and one of the least usefully written about, because the question worth answering is narrow: what kind of image is this, and what does that kind of image do to the answer? An error dialog, a spreadsheet screenshot, a photo of a paper form, a chart, a handwritten note and a whiteboard are six different problems wearing the same shape. They fail in six different ways, and only one of those ways announces itself.
Forty-seven of the 60 models in MultiChats accept an image upload, including 14 of the 21 you get on the free plan, so vision is close to a default. That makes the failure modes the interesting part.
The question does more work than the picture
"What is this" is a request for a description, so a description is what you get. The model has no way to know whether you wanted a diagnosis, a translation, a transcription, an opinion on the design or the one sentence that tells you which button to press. Faced with that, it writes the safest thing, which is an accurate account of what is visible plus a plausible general explanation. Both halves can be correct while the whole answer is useless to you.
Naming the outcome costs you eight words and changes the reply completely. "Which of these buttons do I press to stop this happening again" is a different question from "transcribe every number in the third column" and both are different from "what is this document asking me for". Say the verb.
The second half of this is context the picture cannot carry. An error message is a string that software vendors reuse across a decade of releases, so the fix that matches it depends on your operating system, your version, what you did in the sixty seconds before it appeared and what you already tried. None of that is in the photo. If you leave it out, the model fills the hole with the most commonly written-about case, which is usually an older version than yours, and it will not flag the substitution. Say your version. Say what you already tried. That single sentence removes most of the confident wrong answers you will ever get from a screenshot.
The same principle covers the images that have nothing to do with software. A photo of a washing machine control panel is unreadable without knowing what you were trying to do with it. A page of a contract means one thing to the person signing it and another to the person who wrote it. Tell the model which of those you are.
Six pictures, six different failures
The kind of image decides where the answer goes wrong, and the failure is rarely a refusal. Models read images optimistically, so what you get back is a smooth answer with a soft spot in it. Treat the rows below as patterns to watch for.
What you photographed | Usually reliable for | Where it quietly fails | Ask this instead |
|---|---|---|---|
Error dialog or crash box | Transcribing the code, naming the product and the general class of fault | Prescribing a fix for a different version of the software, stated with full confidence | Give your OS and app version in the same message, then ask which of the visible buttons to press |
Spreadsheet screenshot | Explaining a formula, describing the layout, guessing what a column is for | Precise values in dense rows, small text, and drift between a number and the row it belongs to | Paste the numbers as text and keep the screenshot for the layout, or crop to the six rows that matter |
Photo of a printed form or letter | Telling you which fields are yours, decoding official phrasing, spotting the deadline | Anything defined by absence: the box nobody ticked, the page that is missing, the signature that was never added | Ask what a correctly completed version of this page would contain that this one does not |
Chart from a report | Trend, shape, axis labels, what the chart is arguing | Values between gridlines, which it will supply anyway with invented precision | Ask for the direction and the axis units, and ask it to list the values it could not read |
Handwritten note | Tidy print, short lists, headings | Cursive, crossings-out, personal shorthand, and digits that share a silhouette such as 1 and 7 or 0 and 6 | Ask for a transcription with every uncertain word marked, then correct the marked ones yourself |
Whiteboard photo | Overall structure, arrows, the topic under discussion | Glare, a steep angle, faded marker, text crammed at the edges, and the order things were written in | Shoot it straight on in two halves, ask for the structure first, then go back for detail section by section |
Three of those six are the same underlying failure: the model read something it could not actually see clearly and did not tell you. That is the one to build a habit around. The fourth, the form, is different in kind, because a picture of a page is evidence of what is on the page and almost no evidence at all about what should have been. A model asked to check a form will check the words in front of it. It will not miss the empty field on your behalf unless you point at the shape of the thing and ask what is not there.
Where it will be wrong and sound sure of itself
Small text is the first one. A full-screen screenshot of a spreadsheet scaled down to fit an upload is a picture in which the numbers have stopped being numbers, and the model will still read them. Crop before you send. A tight crop of the eight cells you care about beats the whole window every time, and it sidesteps the 10MB ceiling on the free plan without you having to think about it.
Dense numeric tables are the second, and they are worse than small text because they fail halfway. The model gets the column headers right, gets four of the six figures right, and misaligns the fifth by one row. There is nothing in the tone of the answer that separates the four from the fifth. If the answer depends on the exact figures, type the figures. Twelve numbers typed by hand cost you a minute and remove the entire category of error.
Handwriting is the third, and it degrades in a way most people do not expect. Neat block capitals are read well. Ordinary adult cursive with your own abbreviations in it is read as a fluent guess. If you ask for a transcription and the model returns clean prose with no hedging on a page you know is messy, treat that as a warning.
Absence is the fourth, and it is the only one that no amount of image quality fixes.
And then there is the error message with the plausible fix for the wrong release, which deserves naming separately because it is the single most common way this goes wrong in practice. The remedy is cheap. Ask the model to say which parts of the image it could not read, and ask it what it assumed about your version. A model that has assumed something will usually admit it when asked directly, and the admission is more useful than the fix. It is also the fastest way to find out that the screenshot you sent was too compressed to be worth sending, which you would otherwise discover three replies later.
Running the same image past a second model from a different family is the other check worth the twenty seconds. Two models that agree on a transcription are worth considerably more than one model that sounds certain. When they disagree, you have learned exactly where to look, and the disagreement almost always lands on the cell, the word or the digit that was genuinely ambiguous in the picture. This works best across families, because two models built by the same lab on the same data tend to misread a smudge the same way. Pick the second one from a different provider in the picker and the check earns its keep.
Which models can see, and where the picker stops covering you
The attach step is guarded. If the model you have selected has no vision, the app refuses the image at the moment you try to attach it and tells you to switch models, on web and on mobile alike. You cannot accidentally send a photo to a model that was never going to read it.
What is not guarded is the switch afterwards. Once an image is sitting in a conversation, nothing stops you from switching that conversation to a model without vision and carrying on. That model is told an image was attached that it cannot read, so it can tell you as much, but the app shows you no warning at the moment you switch. If the picture matters to your next question, keep the conversation on a model that can see it.
The message-level menus behave differently on the two platforms, which is worth ten seconds of your attention because the same words do opposite jobs. On mobile, Try again replaces the answer that is there, and Branch here starts a separate thread. On the web, Try Again is the one that starts the separate thread, and Re-generate is the one that replaces. On a message carrying an attachment, mobile narrows both menus to models that can see; the web narrows Re-generate and leaves Try Again showing everything. So if you are on the web and you want a second opinion on an image, either pick a vision model deliberately from that list or use Re-generate.
On phones the capture path is built in. Tap the plus button in the composer and the sheet opens with Camera, Photos and Files, and Camera is the one that matters here, because most of these images are things in the physical world: a screen you cannot screenshot, a letter, a label on the back of an appliance, a whiteboard on the way out of a meeting. Photographing a screen deserves its own note, since it is what most people do with an error box. Turn the phone slightly off axis to kill the reflection of your ceiling light, and get close enough that the dialog fills the frame.
The free plan allows one attachment per message, up to 10MB, three uploads a day. Three a day is enough for the printer error and the tax letter and not enough to iterate lazily, so it rewards the discipline this whole article is about: crop it, then write the question, then attach.
Before you photograph something with your name on it
People point cameras at things that carry personal data, which is the whole reason this use case exists. The bank letter you cannot decode has an account number printed at the top of it, and the medical form has your date of birth halfway down.
Here is the accurate position, and you can check every part of it in the app: we do not train on your conversations. Some providers might, depending on which model you send the image to, and where we know of a difference, the model info card in the picker carries a notice. At the October 2026 check, six of the 60 active models carried one, four of them accept images, and each notice is worded in plain terms. Grok 4.3 and Grok 4.3 Reasoning both say, in those words, that xAI may use your conversations to train Grok models. Models routed through OpenRouter say the providers behind them may briefly retain requests and do not train on your data. Open the card before you send a photo of something sensitive and read the line.
The other half of this is yours: crop out what the question does not need. The model does not need the account number to explain the letter, and a crop is a better prompt anyway.
Before sending the image, check these details. Crop to the part that holds the answer. Say what you want out of it in a verb, and give your version number if it is an error. Then read the reply for the sentence where the model tells you what it could not make out, and ask for it if it is missing.