Cursor IDE
I would like the chat to not compress the images or if it does allow the ai to still work with the raw image as I often attach it instead of dropping it in the workspace I was an aware of this. at first and didn’t know why the ai kept using a low res version of the image I provided
MacOS
Hey, thanks for the feature request, and good catch. You’re not the first user to run into this.
You’re right. Right now, images attached in chat get downscaled to a max resolution before the model sees them. That means small text in screenshots and dense UI can become hard for the AI to read. There’s currently no way to turn this off or send the original image, and the UI doesn’t clearly say this is happening. I agree it’s not obvious.
A couple honest workarounds for now:
One quick warning: the idea of putting the image in the workspace and asking Cursor to read it won’t help. When reading images there, it still scales them to the same limit, so you won’t get full resolution that way.
I’ve passed the request to keep the original resolution (or add a configurable limit) to the team. I can’t share an ETA, but it’s tracked. I’ll post an update in the thread if we get one.
The measurement on this is worse than it sounds. I tested a full-page capture once: about 3066x28800 going in, and roughly 276x2600 by the time the model actually saw it. Text under 3 pixels tall. Aspect ratio is preserved, so on a very tall screenshot both dimensions get squeezed and the width ends up tiny. That’s why the crop advice works, you stop feeding it height that eats your width. The deeper fix is to stop sending pixels for anything that’s really text. If the model gets the text plus each element’s position as structured data, resolution stops mattering, a label reads the same whether the capture was 200px or 2000px wide.
I wrote up why this happens across Claude, Cursor and the rest, and what actually fixes it: https://slimsnap.ai/blog/full-page-scrolling-screenshot
Hey, thanks for the measurement, the numbers make the issue really clear. Yep, that’s exactly it. On very tall screenshots, keeping the aspect ratio with a hard cap on the longer side also shrinks the width, so the text turns into a blurry mess. That’s why the advice to crop to the needed area works.
The idea of using text plus structured coordinates instead of pixels makes sense. When the details are basically text like logs, terminal output, or code, it’s more reliable to paste them as text and crop screenshots to the exact fragment you need.
On your request to keep the original resolution or make the limit configurable, we’re tracking it as an issue. I can’t share an ETA yet, but if there’s an update, I’ll reply in the thread.
The crop-or-paste-text route misses one case: sometimes you need the visual itself, a full layout or a long form, not just the text in it. There the fix is to slice the tall capture into page-sized frames, each one under the dimension limit, and paste them in order. Every frame stays sharp and you keep the layout, instead of one squeezed column. If you do add auto-resize on your side, slicing tall images into readable pieces beats scaling one giant image down to fit, that’s the part most tools get wrong.
Great add-on, and fair point. For cases where you really need the visual layout (a full layout or a full long-form view), not just the text from it, the advice to crop it or paste the text won’t actually help.
Splitting a tall screenshot into page-sized frames under the limit and attaching them in order is a solid practical workaround. Each piece stays sharp, and the layout is preserved, instead of ending up with one heavily compressed tall image. Thanks for spelling it out.
On the request itself (keep the original resolution or make the limit configurable), we’re tracking it as an issue. If there’s an update, I’ll reply in the thread.
One last practical bit for anyone doing the slicing by hand: overlap the frames a little so nothing gets cut in the middle of an element, and watch out for sticky headers repeating in every frame, they can confuse the model about what is actually on screen. Glad the request is tracked.