Why Your Photos Look Blurry When You Send Them to Android

Short answer

Because the message went as MMS, which caps attachments at roughly a megabyte. Your phone re-encodes the photo until it fits, which for a modern camera image means throwing away most of it. If the conversation goes as RCS instead, the ceiling is high enough that this stops happening. If it cannot, send a link or a file instead of an attachment.

The number that causes this

MMS was designed around a payload of roughly one megabyte. Carriers set their own limits and they vary a little, but that is the order of magnitude, and it has barely moved in twenty years.

A photo from a current phone camera is several megabytes. A short video is tens or hundreds. So when you attach a photo to a message that is going as MMS, your phone does the only thing it can: it re-encodes the image, dropping resolution and raising compression, until the result fits under the cap. Then it sends that.

The result arrives looking soft, blotchy around edges, and with visible blocking in areas of flat colour like skies and skin. It is not a rendering problem on their end and it is not their phone being bad. The file that arrived genuinely is that small.

Two details make it worse than the single number suggests. The cap that applies is the lower of the two carriers involved — yours and theirs — so one person on a restrictive network sets the limit for both. And in a group, it is the lowest across everyone, which is one of several reasons mixed group chats degrade so badly.

Why it is fine to some people and not others

This is the observation that usually brings people here: the same photo, sent from the same phone on the same day, looks perfect to one friend and terrible to another.

That is the whole diagnosis. The conversation that looks fine is running on something better than MMS — either iMessage, if they are on an iPhone, or RCS. The one that looks terrible is on MMS. Nothing about your phone or your photo differs between the two; the road differs.

This is also why the problem can appear and disappear with the same person over time. If their RCS registration lapses, or they lose data coverage, or they change carrier, your conversation silently drops to MMS and the photos get worse. Nothing announces this. The checker exists precisely because that switch is invisible from the message list.

What RCS actually changes

RCS raises the ceiling by a large factor — enough that a normal photo goes through untouched and a short video usually does too.

What it does not do is remove the ceiling. There is still a limit, it is still enforced per carrier, and a long 4K video will still be compressed or refused. RCS turns “every photo is ruined” into “very large files still need another route”, which is a completely different problem and a much smaller one.

It also does not help retroactively. Photos already sent as MMS are gone in their compressed form. You have to send them again.

Three ways to send the real file

When the conversation cannot carry the photo — because RCS is not available, or because the file is genuinely huge — stop fighting the message and use a different channel. These are ordered by how little effort they demand from the recipient.

Every phone has a share sheet, and both platforms have a way to generate a link to a photo or album that anyone can open in a browser without an account. Send the link in the message. The link is a few dozen characters, so it sails through MMS untouched, and what the recipient opens is the original file at full resolution.

This is the best option in almost every case and it is the one people forget exists. It also works for whole albums, which attachments do not.

The catch: links expire on some services, and a link is a public URL. Do not use this for anything you would not want forwarded.

2. Use a cloud storage app

Google Drive, Dropbox, OneDrive, iCloud. Upload, share, send the link. Functionally similar to the option above but with more control — you can revoke access, set permissions, and the file stays where you put it.

The catch: more steps, and the recipient may need an account depending on how you share it.

3. Send it as a file rather than a photo

This one is less obvious. Attaching an image through a file browser rather than the photo picker sometimes routes it differently and avoids the automatic downscaling. Emailing it to yourself and forwarding also works, crudely.

The catch: it does not defeat the MMS size cap. If the file is over the limit it will still fail or be compressed. This helps in the middle ground where a photo is being downscaled more aggressively than it strictly needs to be.

What does not work

“HD” or “high quality” toggles. Some messaging apps have a setting for sending media at higher quality. It has no effect when the message goes as MMS — the cap is enforced by the network, not by a preference.

Sending it more than once. The compression is deterministic. The second attempt produces the same file.

Turning the photo into a video, or a video into a GIF. These make things worse. GIF is an ancient format with a tiny colour palette and no useful compression for photographic content.

Screenshotting the photo and sending the screenshot. People genuinely try this. It reduces quality first and then gets compressed anyway.

The honest fix

If you send photos to the same person regularly and they always look bad, the durable answer is to get that conversation off MMS, which means both of you on RCS — or, if their line will not support it, moving that particular relationship to an app that does not have this problem at all.

Start by finding out which of those situations you are in. Our checker will tell you whether the conversation is capable of RCS today, and the carriers page covers the case where the handsets are fine and the network is the obstacle.

Check your own setup

Check whether your conversation with this person is on MMS or RCS — that single fact decides whether photos arrive intact.

Run the checker

Version facts on this page: not verified yet — the site-wide verification pass has not been completed. See the update log

Related guides

Published 1 September 2026. Last reviewed 1 September 2026. This guide depends on facts F21, F9, F1 in our verification table — if one of those changes, this page gets rewritten and the change is logged in the update log.