How to Reduce Image File Size Before Uploading to Any Website

Why upload limits exist and what they actually mean

Most websites enforce file size limits on image uploads for two reasons: server storage costs and page performance. A 6 MB uncompressed phone photo that gets embedded into a product page or blog post adds seconds to page load time and costs the site operator real storage. Upload limits are the mechanism websites use to prevent this.

Common limits in 2026:

• WordPress / page builders: 2–8 MB default (configurable by the server administrator)
• Shopify: 20 MB per image file, but recommends under 1 MB for web
• Squarespace / Wix: 20 MB, but images over 1 MB visibly slow template rendering
• Web forms and portals: 1–5 MB, often without a clear error message when exceeded
• Google Search Console: 100 MB for uploads, no web delivery concerns
• Social media: 5–30 MB depending on platform (separate from general website uploads)

The goal is not to scrape under an arbitrary limit — it is to deliver the visual result at the smallest file size that is still visually indistinguishable from the original. That target is almost always under 500 KB.

The two-step approach — why both steps are necessary

Resize and compress are two different operations that target different sources of unnecessary file size.

Resize reduces pixel dimensions — the number of pixels in the file. A phone photo at 4032×3024 contains over 12 million pixels. A website displaying that image in a 1200 px wide content column will display it at approximately 1200×900 px. The extra 10 million pixels are stored in the file, transmitted to the browser, and then discarded by the browser's rendering engine. Resizing eliminates them before transmission.

Pictuary's Resize tool uses proportional scaling by default, so leaving the height field blank preserves the original aspect ratio. The withoutEnlargement constraint also applies on every operation: Pictuary will never output an image at pixel dimensions larger than the source — protecting against quality-degrading upscaling.

Compress reduces the data used to encode each pixel. After resizing, the remaining pixels are re-encoded at a lower fidelity — but at quality 80, that reduction is imperceptible.

The two operations compound each other. Resizing from 4032×3024 to 1920×1080 reduces pixel count by approximately 85%. Compressing the resized image at quality 80 WebP reduces the encoded size by a further 60–70%. The combined result:

Compressing without resizing first — the single most common mistake — typically achieves only a 30–50% reduction from the 6 MB source, leaving a 3–4 MB file that is still too large for most upload fields.

What file size to target by use case

Why pixel dimensions matter more than you expect

A common assumption is that "the image looks fine" on screen before resizing, so resizing must be optional. This is not accurate. The image looks fine because the browser is doing the work — it is scaling the 4032 px image down to 1200 px for display, discarding the surplus pixels at render time. The full 6 MB is still being downloaded by every visitor before that scaling happens.

Resizing before upload shifts that work from every visitor's browser to a one-time operation on your machine. The visitor downloads a 350 KB file. The browser renders it immediately. Page load time improves measurably. Images are the largest single contributor to page weight on most websites — typically 60–70% of total download size on unoptimized pages.

For pages where images are a major component of total page weight — product pages, portfolios, blog posts — this difference is significant. Google's Core Web Vitals measure Largest Contentful Paint (LCP): how fast the largest visible element on a page loads. Oversized images are the most common cause of poor LCP scores.

Note: if the upload field rejects your image after compressing, do not be tempted to upscale it to meet a minimum dimension requirement. Upscaling adds pixels through interpolation — not real image detail — and degrades rather than improves quality. If the platform requires larger pixel dimensions, start from a higher-resolution source.