Can ChatGPT Compress a Photo? We Measured What Comes Back

Can ChatGPT compress images? The short answer, platform by platform

Three of the five chatbots we tested can return a compressed JPG; two cannot return a file at all; and none of the three that can ever saw the photo you attached. Here is what each one did with a 10,044,627-byte, 5712 x 4284 iPhone 15 photo on October 15, 2026.

We re-checked Gemini on 3.8 Flash, the current Flash model, on October 16, 2026, with a different image (a PNG graphic rather than the iPhone photo): the same result, no file returned, and a list of other tools instead (Squoosh, TinyJPG, TinyPNG, Paint, Preview and a Python script using Pillow).

The returned files are 90% to 95% smaller than the photo on disk, which sounds like a triumph until you notice how: by discarding resolution you did not ask to lose, before the model got involved. The chatbot's own compression step removed 29% to 60% of what remained. If you wanted "the same photo, smaller file", none of the three delivered it. If you wanted "small enough to email", all three did, and that is a legitimate use we come back to in section 8.

The pattern is the same whichever assistant you ask, so the rest of this guide treats "ChatGPT" as the lead example and names the others where they differ.

Five words this guide uses

The whole story turns on the difference between a photo's size in pixels and its size in bytes, so it is worth pinning down five terms before the numbers.

• Pixel dimensions are the width and height of the picture, for example 5712 x 4284. Multiply them and you get megapixels (24.5 MP here). Dimensions decide how large a photo can be printed or zoomed before it looks soft.

• File size is how many bytes the photo takes up on disk, for example 10 MB. File size depends on dimensions and on how aggressively the JPEG encoder squeezed the pixels. Two photos with identical dimensions can differ in file size by ten times.

• Resampling (resizing) throws pixels away or invents them. Going from 5712 to 2048 wide keeps about one pixel in eight. It is the cheapest way to make a file smaller and the one that cannot be undone.

• EXIF is the metadata block a camera writes into the file: make and model, date, exposure, and often the GPS position. Our EXIF guide covers what a photo's metadata gives away.

• Color profile and gain map are two further blocks of data riding inside an iPhone JPEG. The profile (Display P3 on recent iPhones) tells software how to interpret the colors. The gain map is what lets the photo show brighter-than-white highlights on an HDR screen; we explain it in why HDR photos look flat when shared.

Hold on to the first two. "Compress" in everyday speech means "make the file smaller". To a chatbot's upload pipeline it means "make the picture smaller", and nobody tells you which one you got.

How we tested

One file, one day, one script. We used a single photo so that every platform started from the same bytes, and we measured every returned file the same way rather than trusting any chatbot's description of it.

The photo. IMG_4522.JPG, taken on an iPhone 15 on October 15, 2026: 10,044,627 bytes, 5712 x 4284 pixels (24.47 MP), Display P3 color profile, Apple's HDR gain map stored as a second frame inside the file, and a full EXIF block with camera model, timestamp and GPS. A completely ordinary modern phone photo, in other words, and at 10 MB inside the documented upload limit of every platform tested (ChatGPT's image upload limit is 20 MB per image, Perplexity's 40 MB per file, Gemini's 100 MB; Anthropic's two documents give 10 MB and 500 MB for claude.ai, and the photo was accepted).

The prompts. Each one was pasted verbatim into a fresh chat in the platform's desktop web app, between 15:47 and 16:10 UK time:

• Prompt A: Compress this photo so the file is smaller. Keep it as a JPG and give me the file back to download.

• Prompt B (same chat, after A): Before you did anything to it, what exactly did you receive: the file size in bytes, the pixel dimensions, and whether it still had EXIF metadata (camera model, date, GPS)? Then give the same three for the file you returned. Report the actual values, not estimates.

• Prompt C (fresh chat): Compress this photo to under 1 MB and give me the file back to download.

• Prompt Z (ChatGPT only, fresh chat, 21:18 UK): Prompt A again, with the photo attached inside a .zip archive instead of as an image. This is the ".zip trick" that forum posts and Google's AI Overview recommend for keeping full resolution; we tested it after the main runs.

The measurement. Every file that came back was read by one Python script (Pillow, NumPy, scikit-image): bytes, pixel dimensions, EXIF presence and tag count, ICC profile, XMP, progressive flag, chroma subsampling, an estimate of the JPEG quality setting inverted from the quantization tables, and an MD5 hash. The "what did you receive" figures in the tables are each platform's own answer to Prompt B. For Claude we could also check that answer independently: the same photo attached to a Claude session arrived as 1,779,417 bytes at 2576 x 1932 with no EXIF, which is exactly what Claude reported.

What we did not test. The mobile apps, batches, PNG or HEIC input, and the .zip route on any platform other than ChatGPT. We say so again where it matters. Everything below is "measured on one file on October 15, 2026", not a statement about how any platform always behaves.

Step one happens before the model: the upload

The compression you asked for had already happened, and then some, before the chatbot read your message. All three platforms that could inspect the file reported receiving a much smaller picture than the one we attached, and none received the metadata.

So does ChatGPT compress images when you upload them? Yes, in the sense that matters: the picture is made smaller before the conversation starts. This is not a bug and it is not hidden, exactly; it is simply not mentioned in the chat. OpenAI's own help center says that for image inputs "images are resized before analysis, affecting their original dimensions" and that "the model doesn't process original file names or metadata" (ChatGPT Image Inputs FAQ). Anthropic's platform documentation goes further and publishes the ceiling: on its high-resolution tier the maximum long edge is 2576 pixels, and "images larger than either limit are downscaled before processing" (Claude vision docs). Our photo arrived at Claude at 2576 x 1932, which matches that figure to the pixel. Perplexity's help center documents a 40 MB file limit and says nothing about resizing (Perplexity file uploads); the 1440-pixel ceiling we measured is observed, not documented.

The reason is cost. A vision model is billed and budgeted in tokens, and a 24 MP photo would cost far more to look at than a 3 MP one without telling the model anything extra about what is in the picture, so every provider shrinks images to a working size on the way in. Our guide to LLM image token costs walks through the per-provider formulas; for this guide the point is simpler. The resize is for the model's benefit, it happens on every image you attach whether you ask for compression or not, and the model itself has no way to know it happened.

People notice. A post in a beginners' photography group on Facebook, which ranks on page one for this question with over 130 comments, puts it in the plain words: "it lowered my 8mp 2123x 3900 to 3mp 1024x1536. While I like the outcome..." The surprise is always the same shape: the result looks fine on a phone screen, and the pixels are gone.

Step two: what the chatbot's compression actually did

Once the model had the reduced copy, it did what you asked: it wrote a Python snippet, re-encoded the JPEG at a lower quality setting, and handed back a file. Measured against the photo on disk, every returned file was 90% to 95% smaller. Measured against what the model actually had to work with, the saving was 29% to 60%, and in two cases the "compression" did almost nothing at all.

Three things in that table are worth a second look.

"Under 1 MB" is a trivial target once the upload has done the work. A 1.5-megapixel image at JPEG quality 94 is under 1 MB without trying, which is why Perplexity's "under 1 MB" file is larger than its plain-compress file: with a generous budget it simply used a higher quality setting. Claude returned the byte-identical file for both prompts (same MD5), because its first attempt already landed at 961 KB. ChatGPT's two files differ by one quality step. The target you typed was met, but the work of getting a 10 MB photo under 1 MB was done by the resize at upload, not by the prompt.

Every chatbot chose a quality setting you would not have chosen. Claude's file is encoded at roughly libjpeg quality 60, which is visible on fine detail at 1:1; ChatGPT's at about 75 to 80; Perplexity's at 80 and 94. None asked. All three used 4:2:0 chroma subsampling (color detail stored at half resolution) and all but one wrote a progressive JPEG. These are defensible web defaults. They are also decisions made on your behalf, on a copy of your photo, by a script you did not see.

The savings each platform reported were true and meaningless. "45%", "46%" and "60%" are accurate descriptions of the step the model performed on the file it had. They just describe the wrong baseline.

A fair comparison of visual quality across the three directly attached files needs a side-by-side crop at a common display size, and we have not published one here, because each platform's resize used its own resampler and a single similarity score mixes the two effects together. What we can say without a caveat is in the next section, after one more test.

The .zip trick, tested. The AI Overview for this question says that "users often upload high-resolution images inside a .zip archive so Code Interpreter can process them losslessly", citing a two-year-old blog post. We tried it once, on ChatGPT, with the same photo and Prompt A. It worked: the archive bypasses the image pipeline, the code sandbox unpacked the original 10,044,627 bytes, and the returned JPEG is 5712 x 4284, every pixel intact, at 5,582,118 bytes, 44% smaller, encoded at roughly quality 78. Because the file never went through the resize, the Display P3 profile survived too. ChatGPT's report this time was accurate: "approximately 44% smaller than the original 10.04 MB image. The image dimensions are unchanged, and the camera metadata has been removed to help reduce the file size." That last clause is the one honest metadata statement in the whole test, and note what it means: the metadata was removed by ChatGPT's own script, deliberately, and you were told. The gain map was still dropped (Pillow, the library the sandbox used, does not write one). Measured against the original at full size, luma SSIM was 0.986 at 37.4 dB, a true like-for-like figure because no resampling is involved. One run, one platform, one day; we have not tried the archive route on Claude or Perplexity, and a feature that works because an archive slips past a pipeline is not one anyone has promised to keep.

So the model can compress your photo properly. The problem was never the model; it is the door the photo comes in through.

What went missing that nobody mentioned

Three blocks of data were removed from every returned file, and no chatbot mentioned any of them unprompted: the EXIF metadata, the Display P3 color profile, and the HDR gain map. One of those removals is arguably a favor, one is harmless on most screens, and one quietly turns an HDR photo into an SDR one.

EXIF and GPS: gone, and the chatbots said otherwise. Asked directly (Prompt B), all three platforms reported that the file they received had no EXIF data, and each concluded that its compression therefore "did not remove" any metadata. That is literally true and practically wrong: the camera model, timestamp and GPS coordinates were in the file we attached and are not in the file we got back; they were removed by the upload pipeline, which the model cannot see. Claude came closest to saying so: the upload "was probably already stripped before it reached me, though I can't tell where that happened". For a photo you are about to post publicly, losing the GPS position is a good outcome. The problem is that you cannot rely on it, because nobody promised it, and you cannot keep the metadata when you want to (a photographer's copyright field, a client's shoot date), because nobody offers a switch.

Color profile: converted correctly, then dropped. The source photo was tagged Display P3, a wider color space than the sRGB most screens assume. Every file returned from a direct attachment was untagged (the .zip route, which skipped the image pipeline, kept the tag), so we tested what the pixels actually contained rather than assuming the worst: we compared each file against the original's raw values and against the original converted from P3 to sRGB, on the 1% most saturated pixels. Every platform matched the converted version (mean error 0.8 to 3.4 on a 0-255 scale) and none matched the raw values. In plain terms, the colors were translated properly and the untagged file renders correctly on an ordinary screen. What is lost is the wide-gamut headroom: colors outside sRGB are clipped. On this photo that difference averaged 3 on a 0-255 scale across the frame, small enough that you would not see it on most displays. This is not a defect on any platform, ours included; it is a limit of the chat route that nobody states.

HDR gain map: gone everywhere, by default. Recent iPhones store a gain map alongside the normal picture so that highlights can exceed white on an HDR display. Not one returned file from any chatbot carried it; the picture that comes back is standard dynamic range, full stop. If you have ever wondered why HDR photos look flat when you share them, this is one of the ways it happens. We should be clear that a plain "compress this" produces the same result on Mochify: our standard path drops an existing gain map too. The difference is that Mochify has a path that keeps it, which we come to in the workflow section.

If any of these three matters to you, the chat route is the wrong tool, however good the result looks on your phone. Compress the photo you actually have at mochify.app/flow instead.

Why the chatbot told you the wrong number (and how to check)

The chatbots were not lying. The model's only knowledge of your photo is the copy that arrives after the upload step, so when it reports "1.64 MB to 898 KB" it is reporting what it saw, and when it says "no metadata was stripped" it is reporting that the copy it received had none to strip. ChatGPT went as far as calling 2048 x 1536 "the original dimensions". From inside the conversation, it was. The .zip run proves the point from the other side: given the real file, the same ChatGPT reported the real size (10.04 MB), the real saving (44%) and what it had removed. The arithmetic was always fine; the input was not.

This is the single most useful thing to understand about asking an assistant to process a file. The assistant and the file are not in the same place. The file goes through a pipeline (size checks, resizing, metadata removal, format normalization) that exists for the model's benefit, and then the model is handed the result with no record of what changed. Anything the model then tells you about "the original" is a description of the copy.

You can check this yourself in under a minute, on any platform, with the photo you care about.

1. Note the real figures first. On a Mac, select the photo in Finder and press Command-I: Size (in bytes, in brackets) and Dimensions are in the More Info section. On Windows, right-click, Properties, Details tab: Dimensions and Size. On an iPhone, open the photo, tap the "i" button: the dimensions and megabytes are under the camera line.

2. Attach the photo and ask the question before you ask for anything else. Paste Prompt B from section 3 as your first message, or shorter: What are the exact pixel dimensions and byte size of the file you received, and does it contain EXIF data?

3. Compare. If the dimensions the assistant reports are smaller than Finder's, the resize has already happened and every later figure in the chat is relative to the smaller copy. If it reports no EXIF and your photo had GPS on, the metadata is already gone.

4. Download the result and check it the same way. Finder's Get Info or Windows Properties will show you the true dimensions of what came back. If you want to see the color profile and metadata too, Preview on a Mac (Tools, Show Inspector) and most photo tools will list them; an empty EXIF panel on a phone photo is the tell.

If the figures match, you are on a route that preserves the file and the chat's numbers can be trusted. In our test, on October 15, 2026, no chat route did.

When the chat route is fine, and when it is not

If "smaller" is the whole requirement and the photo will be viewed on a phone or in an email, asking a chatbot is a perfectly good way to get a sub-1 MB JPG, and you do not need this guide to use it. The problem cases are the ones where the pixels, the metadata or the HDR carry value you cannot get back.

Fine:

• A photo attachment for an email or a messaging app with a size cap. A 2048-pixel, 900 KB JPEG looks correct in any inbox.

• A quick image for a web form, a support ticket or a chat message, where the recipient will look once on a screen.

• A one-off, where you have the original safely elsewhere and only the small copy needs to travel.

• Gemini's and DeepSeek's answer, which was to decline and name other tools, is also fine. It is the honest version of the same limit.

Not fine, or not without checking:

• Anything you might print or crop later. A 3 MP file prints acceptably at roughly 4 x 6 inches; the 24 MP original prints at poster size. The pixels do not come back.

• Marketplace and product listings. Platforms zoom and recrop. A 1440 x 1080 upload is below the point where that works well, and the published recommendations sit well above it (Etsy recommends 2000 px, Amazon 1600 px on the longest side). Our guide to why free tools reject camera files covers the related failure in the other direction.

• Anything where the metadata matters either way. You cannot keep a copyright field or a capture date through the chat route, and you cannot be sure the GPS is gone either, because nobody documents it.

• HDR photos you want to stay HDR. The gain map does not survive.

• Batches. The free tiers of the chat platforms cap uploads per day and per message, and each photo is a conversation turn.

• "Compress but keep the quality." The chat route cannot do this, because the quality decision was made at upload before you spoke.

The middle case: attaching the photo inside a .zip, which on ChatGPT gave us the full 5712 x 4284 at 5.6 MB. It keeps the pixels and (on this run) the color profile; it still drops the HDR gain map, removes the metadata without offering to keep it, costs a sandbox step and a sign-in per photo, and depends on an archive slipping past a pipeline that nobody has promised will keep letting it through. Workable for one photo today; not a workflow.

A quick test for which side you are on: if someone will ever look at the result at more than phone size, or do anything to it other than look, keep the pixels.

Mochify workflow: compress the photo you actually have

Mochify receives the file you attach, all of it, and compresses that. On the same 24 MP photo, the same day, a plain compress returned every pixel (5712 x 4284) at 4,377,466 bytes, 56% smaller than the original; the HDR-preserving run returned every pixel plus the gain map at 4,288,854 bytes, 57% smaller; and "under 1 MB" returned 945,244 bytes at 3361 x 2521, which is 2.7 times the pixels ChatGPT's file holds and 5.4 times Perplexity's. The engine received the original bytes in every run, so the savings are against the real file, not a copy.

The interface is the same as the chat route, which is the point: you drop the file and say what you want in plain English. Magic Flow reads the instruction with a language model, then hands the work to our C++ engine; nothing about the photo is reduced on the way in.

Privacy, stated per surface rather than in one sentence. Your photo travels to api.mochify.app over HTTPS, is encoded in memory and wiped immediately: no disk writes, no logs containing file data, and never used to train AI. That holds for the web app, the CLI, the REST API and both MCP servers. The hosted MCP server additionally holds the compressed output behind a short-lived URL on files.mochify.app for up to five minutes so the agent can fetch it; the original is still discarded at once. The local CLI and local MCP server (mochify serve) have no pickup store: the compressed bytes come straight back to your machine. Video is the one format that never leaves your browser, because the video engine runs client-side; images and PDFs do travel to the API, and we would rather say so than borrow the chat platforms' silence.

Three routes that give an assistant the real file

The lesson of this test is not "do not use AI"; it is that an attachment in a chat window is lossy by construction, so give the assistant a route to the original bytes instead. (The same split is what lets an assistant hide a license plate or every face in a photo without shrinking it: the assistant picks the box on its preview, Mochify redacts the original.) Three exist today, and none of them puts the photo through an upload pipeline:

• An agent with a filesystem (Claude Code, Claude Desktop or any MCP client on your machine) can call the local MCP server or the mochify CLI, which read the file from disk and return a path, so the photo never enters the conversation at all. Setup is in image compression inside Claude Code.

• An agent with a URL can pass it to the hosted MCP server at mcp.mochify.app, which fetches the original and returns a download link. How the Mochify MCP server works compares the two.

• A developer can POST /v1/squish directly with Authorization: Bearer <key>; the request body is the file, so the engine sees every byte. Docs at mochify.app/docs.

Whichever route you pick, the "what exactly did you receive" check from section 7 will return your real dimensions. That is the test of a tool that compresses your photo rather than a copy of it.

Cheat sheet

One 24.5 MP iPhone 15 photo (10,044,627 bytes, 5712 x 4284, Display P3, HDR gain map, EXIF with GPS), October 15, 2026.

Rule of thumb: the chat route changes the picture; a compression tool changes the file. Ask "what exactly did you receive?" before you trust any saving a chatbot reports.

FAQ