No. Does Dropbox compress images? It does not touch them. On 2026-07-18 I uploaded a 4.13 MB iPhone photo and a 1.78 MB transparent PNG, downloaded both, and the sha256 hashes matched my originals exactly. Every compressed looking Dropbox photo I have ever been sent was a preview, not the stored file.
| My test, 2026-07-18 | Uploaded | Downloaded | Verdict |
|---|---|---|---|
| iPhone photo (JPEG) | 4,332,705 bytes | 4,332,705 bytes | sha256 match |
| Transparent PNG (alpha) | 1,863,465 bytes | 1,863,465 bytes | sha256 match |
| EXIF, GPS, timestamps | present | present | untouched |
Scope, stated plainly: that is two reference files, one day, one account, uploaded by hand and downloaded again. It proves what Dropbox did to those exact files on that date, not what every path does forever. The paths that genuinely behave differently, previews, shared links, and Camera Uploads, each get their own section below.
Does Dropbox Compress Images? The Answer Is in the Hashes
Dropbox stores the file you give it and returns the same file, bit for bit. Both of my reference files came back with sha256 hashes identical to the copies on my desk, which is the strongest claim a storage product can make and the one Dropbox actually earns.
This page is one row in a larger project where I push the same two files through every app people upload photos to and record what comes back. Most platforms re-encode. Some resize. A couple mangle. Dropbox is one of the few that does nothing at all, and a Dropbox Community moderator's accepted answer says the same thing in official words: files are not compressed on upload, and downloads return the original.
The reference files behind every number
REF-A is a real iPhone photo: 4,332,705 bytes, 4032x3024, JPEG, full EXIF block including GPS. REF-B is a photographic cutout with true transparency: 1,863,465 bytes, 1240x930, PNG with an RGBA alpha channel. The same pair meets every platform in this series, so when I say Dropbox behaved better than LinkedIn, both faced identical input.
Why a hash says more than a file size
Two files can show the same size in a file browser and still differ in millions of bytes, because sizes get rounded for display. A sha256 hash rounds nothing. If one byte moves, the hash changes completely. Matching hashes on both files means no re-encode, no rescale, no metadata rewrite, no format normalization. Nothing happened.
If the two sizes still look different
A common false alarm: your desktop says 4.47 MB, the Dropbox web interface says 4.48 MB, and the accusations start. Different software rounds bytes differently, and some of it divides by 1000 where the rest divides by 1024. An independent test at WindowsReport hit exactly this, a 4.47 MB upload displaying as 4.48 MB with the bytes unchanged underneath. Compare bytes, or better, compare hashes. Displays round; hashes never do.
What Does No Compression Actually Mean Inside Dropbox?
It means the file you download is the file you uploaded, even though Dropbox has historically compressed things internally. Those two statements sound contradictory. They are not, and the difference is the whole story of lossless versus lossy compression.
Lepton, the compression you were never meant to notice
From 2016 until at least 2022, Dropbox ran uploaded JPEGs through Lepton, its own lossless JPEG repacker. Lepton exploited redundancy in how JPEG stores its internal math to shrink the stored copy by 22 percent on average, across 16 billion images, then rebuilt the exact original bytes on every download at up to 15 MB per second. Think of a zip file that unzips itself before you ever see it. Your pixels never changed, your hash never changed, and Dropbox paid less for disks.
What runs today
Dropbox archived the Lepton project in February 2023 and has not publicly said what replaced it. What I can say is that the user facing contract held in my test: whatever Dropbox does internally in 2026, the bytes it returned to me were the bytes I gave it. The internal storage format is Dropbox's business. The download is yours, and it is intact.
Why Do Dropbox Images Look Smaller When You Save Them?
Because the image rendered in your browser is not the stored file, it is a preview, and saving the preview gives you the preview. This single confusion generates most of the forum threads accusing Dropbox of ruining photos, and none of the top results on this question lay the paths side by side. So here is the table I wanted to find.
| How you grab the image | What you actually get | Full quality? |
|---|---|---|
| Desktop sync folder | The stored original | Yes |
| Download button on the web | The stored original | Yes |
| Link edited to end in dl=1 | The stored original | Yes |
| Right click the web preview, Save image as | A re-encoded preview derivative | No |
| Thumbnail API request | A JPEG or PNG derivative, 2048x1536 at most | No |
The right-click trap
When you open an image on dropbox.com, the page renders a derivative that was re-encoded for fast display. Dropbox's SDK documentation lists the fixed sizes these derivatives come in, from 32x32 up to 2048x1536. Right clicking that rendered image and choosing Save image as writes the derivative to your disk, and community reports have recorded saves a few hundred pixels wide from originals measured in thousands. The person did everything that looks right and got a small soft file, and Dropbox took the blame for a browser habit.
Preview limits by format
Previews also have ceilings, documented on Dropbox's own list of file types that preview: a JPEG or PNG above 100 MB or 50 megapixels gets no preview at all, TIFF gets 200 MB, PSD a full gigabyte. Past the ceiling you see a generic icon instead of the photo. The stored file is still there, still intact, still downloadable. A missing preview is cosmetic, never data loss.
Does Dropbox Compress Photos You Share With a Link?
The stored file behind a shared link is never compressed, but what your recipient sees in the browser is a preview, and what they save from that preview is the preview. Whether they end up with your original depends entirely on which button they press, and on two characters at the end of the URL.
What each link ending serves
A standard Dropbox shared link ends in dl=0 and opens the preview page. Per Dropbox's force download documentation, editing the ending changes the behavior for anyone who clicks it.
| Link ending | What opens | What a save gets |
|---|---|---|
| dl=0 (default) | Preview page | The preview, unless they press Download |
| dl=1 | Direct download | The stored original |
| raw=1 | The raw file in the browser | The stored original |
Sending photos that arrive intact
If the recipient needs your exact file, send the link with dl=1 or tell them to press the Download button, nothing else. If the point is a photo that loads fast and fits wherever it lands, the original is usually overkill: a 4 MB camera photo is more than any screen shows. Shrink it below a megabyte first, then share the small copy, and keep the untouched original in Dropbox where it is safe.
Dropbox Camera Uploads: The One Path That Changes Your File
Manual uploads are byte exact, but the automatic Camera Uploads feature on iPhone and Android can produce a file that differs from the one in your camera roll. This is the exception the marketing never mentions, and it is where the compressed my photos complaints that are not preview confusion come from.
The automatic upload that is not always a copy
The best available explanation, from a long running Dropbox forum thread, is that Camera Uploads can encode its own JPEG from the capture rather than copying the camera roll file, so the two files end up with different sizes and different compression parameters even though they show the same moment. Dropbox has never documented this officially, which is exactly why my test used the manual path: drop the file in, byte identical result. If archival fidelity is the goal, upload from the camera roll yourself instead of trusting the automatic path.
The HEIC to JPG setting
iPhones shoot HEIC by default, and Camera Uploads has a setting called Save HEIC photos as JPG. Dropbox's iOS format documentation is clear about its scope: it only applies to automatic Camera Uploads, and it is off unless you choose it. Turning it on trades fidelity for compatibility, since the conversion re-encodes the image. Manual uploads keep HEIC as HEIC either way. If you need JPGs deliberately, convert HEIC to JPG on your own terms instead.
What Happens to EXIF, RAW Files, and Metadata?
Everything survives. My downloaded photo carried its complete EXIF block, GPS coordinates included, matching the moderator answer cited above and my own hashes. RAW files from real cameras, NEF, CR2, ARW, DNG, are stored as opaque originals too. The JPEG you see when previewing a RAW is a display derivative, not evidence of conversion.
The privacy flip side of perfect fidelity
Perfect preservation cuts both ways. The photo you share by Dropbox link still knows where it was taken, on what phone, at what minute, because Dropbox does not strip metadata the way Instagram's re-encoding pipeline or Facebook's does. For an archive that is exactly right. For a photo headed to a stranger it may not be. Our compressor strips EXIF by default, GPS coordinates, camera model, timestamp, all of it, so the copy you send carries the picture and nothing else.
Where Dropbox Lands Among the Apps I Measured
At the very top, tied with Google Drive: both returned my photo byte identical, and almost nothing else I have measured can say that. So does Dropbox compress images the way chat and social apps do? Not even slightly, and the spread below is why this whole series uses one reference photo.
| Same 4.13 MB photo through | Came back | Change | Pixels |
|---|---|---|---|
| Dropbox | 4.13 MB, byte identical | 0% | 4032x3024 kept |
| Google Drive | 4.13 MB, byte identical | 0% | 4032x3024 kept |
| Discord | 497 KB | 0.3% smaller | 4032x3024 kept |
| Slack | 4.58 MB | 10.9% larger | 4032x3024 kept |
| Microsoft Teams | 3.90 MB | 5.7% smaller | 4032x3024 kept |
| 22.0 KB | 99.5% smaller | resized to 480x360 |
The pattern across the whole series is clean. Storage products treat your file as cargo: Google Drive returned the same matching hashes Dropbox did. Chat tools tinker: Slack actually served my photo back larger than I sent it, and Teams shaved 5.7 percent. Social platforms rebuild your image for their grid, which is how LinkedIn kept half a percent of my bytes. If a photo must survive a journey through the second or third group, it should start that journey small and sharp on your terms.
How to Get the Original File Out of Dropbox Every Time
Every full quality path is a deliberate one. The habit that fails is treating the picture on the screen as the file.
- Sync it. Anything in the desktop sync folder is the original, hash for hash.
- On the web, press the Download button. Never right click the picture.
- Sharing a link? Edit the ending to dl=1 so the click downloads the file itself.
- Embedding somewhere? Use raw=1 to serve the true bytes.
- Sending to a phone user who will save from the preview? Assume they get the derivative, and send dl=1 anyway.
One thing you never need to manage is a quality setting, because there is none. Dropbox documents upload ceilings per door, 350 GB per file through the browser, 2 TB through the desktop app, 2 GB through the mobile app, and no photo on earth approaches any of them. No plan tier changes the storage behavior either: Basic, Plus, Professional, and Business all store and return the same untouched bytes.
Worth saying out loud: perfect preservation is not always the goal. The free Basic plan holds 2 GB, and at 4.13 MB per phone photo that is just under 500 pictures. Archive the originals you care about, and for everything bound for an email, a form, or a feed, send a compressed copy sized for its destination instead of the museum piece.