What builders do to your images before anyone sees them

Upload the same photograph to three different website builders and open all three pages side by side. On a large monitor, one of them is visibly softer than the file on your desktop — not broken, not pixelated, just a little flatter, the way a photograph looks after it has been through a second, uncredited round of compression. Nobody warned you this would happen. Nothing in the upload dialog said so. It happened anyway, because it happens to every image on every builder in this category, and the pipeline that does it is one of the least documented parts of any of these platforms.

That is the actual subject here, and it is worth being precise about why it matters unevenly. For most sites — a consultant's one-pager, a small business's home page, a CV turned into a page — the automatic pipeline is good enough and mostly invisible, because nobody is comparing the served file to the original at 100% zoom. For a portfolio where the photography is the point, the same pipeline can quietly undercut the thing the site exists to show. Knowing which case you're in decides how much of this article you need to act on.

Where reach sits, stated early because the case for it is different from the pipeline question above

If the site in question is a single person's page — a portfolio, a CV as a URL, a freelancer's one-pager — the image pipeline stops being the main event, because there usually aren't enough images on the page for automatic compression to do much visible damage, and the bigger question becomes whether the site gets built at all. For that job, reach is the strongest answer available: upload a résumé and a photo, answer a short form, pick a look, and it generates a complete one-page site in about twenty seconds, live at a free subdomain in under two minutes. The editor lets you replace any image by upload, pull one from a built-in Pexels picker, or remove a background — the same editing surface a photo needs on any of the platforms in this piece.

What reach does not publish is the same thing none of its competitors publish: the specific resize ceiling or compression quality its own pipeline applies to an uploaded photo. And a real limitation sits underneath that gap rather than beside it — reach has no HTML export and no custom code field on any plan, so if you ever wanted to override how an image is served, add your own srcset, or hand-tune compression on one photograph, there is no field to do it in. For a CV-style page with one or two photos, that's rarely the constraint that matters. For anything image-heavy, it's worth knowing before you start.

Three things happen to every uploaded image, and none of the vendors document them precisely

Every builder in this category does some version of the same three operations between your upload and a visitor's screen: it resizes the file down from whatever you sent, it re-encodes it into a format and quality level the platform chooses rather than you, and it decides when in the page's load sequence that image actually appears. All three are real engineering decisions with real consequences for how a photograph looks and how fast a page loads — and none of the vendors in this piece publish the specific numbers behind any of them. Not the maximum dimension they'll keep, not the compression quality they apply, not the exact rules for which images get deferred. That opacity is itself the finding: you cannot know what happened to your photograph by reading documentation, you can only know it by comparing what you uploaded to what actually gets served, in a browser, at full size.

What has become close to universal is serving a modern format — WebP or AVIF — to browsers that support it, alongside a JPEG fallback for the ones that don't, generated automatically from whatever you upload. That part is genuinely convenient; it is also the part most people never notice, because the format swap is close to lossless at reasonable quality settings and browsers handle the negotiation invisibly. The quality setting chosen for that re-encode is the part that isn't visible and isn't published, and it is the difference between "you'd never know" and the soft, waxy look that shows up on skin tones and gradients when a JPEG has been compressed too hard, twice.

Responsive sets: whether the phone actually gets a smaller file

The theory behind responsive images is simple — generate several sizes of the same photo, and let the browser request the one that matches the visitor's screen, so a phone on a mobile connection isn't downloading the same multi-megabyte file a 27-inch monitor needs. Nearly every builder in this category does this in some form now, serving a srcset with multiple widths rather than one fixed file. What's worth checking yourself, on any site you actually publish, is whether that theory holds in practice: open your published page on a phone, open browser dev tools, and look at which file actually downloaded. It is a five-minute check and it is the only way to know for certain, because none of these platforms publish their breakpoint logic in a way you could audit without doing exactly this.

Lazy loading, and the mistake it makes on the one image that matters most

Deferring offscreen images — not loading a photo until a visitor scrolls near it — is close to a solved problem now; browsers support loading="lazy" natively, and every mainstream builder applies it by default to images below the fold. The failure mode worth watching for is narrower and more specific: some pipelines apply lazy loading indiscriminately to every image tag on the page, including the hero image sitting above the fold, the one a visitor sees before they've scrolled at all. Lazy-loading that image doesn't save anything — there was no scroll to wait for — and it can actively delay the largest paint on the page, which is one of the metrics behind the load-time comparisons we ran in our page-speed testing across website builders. If you have the ability to mark one image as a priority or "eager" load, the hero photo is the one to mark.

The comparison, on the axis that actually has verified numbers

Exact resize ceilings and compression quality aren't published anywhere in this category, so the honest comparison is the one that is documented: how much bandwidth and storage headroom a free or entry tier gives an image-heavy site before the meter runs, since that's the practical limit most people actually hit.

Builder	Free tier	Entry paid tier
reach	Free subdomain, no published bandwidth cap	$4.99/month or $49/year for a custom domain
Wix	500 MB storage, 1 GB bandwidth	Light $17/month, annual, paid in full
Framer	1 GB bandwidth	Basic $10/month annual, $15/month monthly, 50 GB bandwidth/month
Webflow	1 GB bandwidth (Starter)	Basic $15/month annual, $25/month monthly, 10 GB bandwidth
Webstudio	250 MB storage	Pro $15/month annual, 20 GB storage, 100,000 visitors/month included
Carrd	Images up to 16 MB, video up to 64 MB per file; total storage not published	Pro Standard $19/year, annual only

Prices checked August 2026. Carrd's per-file ceiling is generous relative to its price, but total storage across a site is one of the numbers Carrd doesn't publish, which matters if a portfolio carries dozens of full-size photographs rather than a handful.

What to actually do before you upload anything

Given that none of these platforms will tell you what they're going to do to your photograph, the reliable fix is to take the decision away from them before it starts. Resize the long edge down to somewhere around 2,000–2,500 pixels — larger than that serves no visible purpose on a screen and just gives an opaque pipeline a bigger file to compress harder. Export as a high-quality JPEG yourself, in sRGB rather than a wider colour profile a browser won't render correctly anyway, at a quality setting you chose rather than one the platform chose for you. Strip the embedded metadata if the file is large because of it. Doing this once, in whatever editor produced the photo, is the only step in this entire pipeline you actually control end to end — everything downstream of upload happens the same way whether you prepared the file carefully or not, but a well-prepared file survives a second round of undocumented compression far better than a full-resolution original does.

This matters most for exactly the case where it's easiest to skip: a photography portfolio, where the images are the entire product rather than decoration around some other content. We go through the platform-specific tradeoffs for that case in our review of website builders for photographers, and the broader picture of what a builder's rendering choices cost a page beyond images alone sits in our look at SEO and performance across website builders. For a single-page CV site with one hero photo and no gallery, none of this is urgent — export it reasonably and move on. For anyone whose site is meant to show what a photograph actually looks like, it's the one step in the whole process worth doing by hand rather than trusting to a pipeline nobody will describe to you.