What actually makes images heavy
Camera sensors, design tools, and screenshot utilities all produce files far larger than the web needs. A full-screen PNG screenshot can be several megabytes; a JPEG straight from a camera can be 5–10 MB. That weight comes from three sources: dimensions (more pixels means more data), bit depth, and encoding efficiency. When that file ends up on a web page, every byte travels over the network and gets decoded on the visitor's device — slowing load times, hurting Lighthouse scores, and burning through mobile data plans.
Before you can slim an image down, you need to know which of those three is the culprit. Most of the time, it's dimensions: people upload 5000-pixel-wide originals into 800-pixel slots. The second most common problem is the format: a PNG screenshot of a photo is often 3–5x heavier than an equivalent-quality JPEG.
The lossy-vs-lossless tradeoff
Not all compression is the same, and this is where most people get confused.
- Lossless (PNG, WebP lossless): preserves every pixel exactly. Great for text, logos, and UI graphics where razor-sharp edges matter — but file sizes stay large.
- Lossy (JPEG, WebP lossy, AVIF): discards detail the human eye barely notices, shrinking files dramatically. Ideal for photos, gradients, and anything photographic.
The widespread myth is that compression always ruins quality. In practice, a lossy encode at 80–85% quality is visually indistinguishable from the original for most photos, while cutting file size by 60–80%. The trick is choosing the right level: start around 80, zoom to 100%, and compare before and after. Look for banding in smooth gradients and smearing around fine detail — if you can't spot a difference, your visitors won't either.
Format choice is the other half of the equation. WebP and AVIF typically beat JPEG by 25–35% at the same visual quality, and all modern browsers support them. JPEG remains the safe default for compatibility with older tooling, while PNG still rules for crisp graphics with text or transparency.
Do it entirely in your browser — nothing leaves your device
You don't need Photoshop, a desktop app, or a server-side API for any of this. Modern browsers can decode, re-encode, and downscale images natively — via the Canvas API and WebAssembly-based encoders — so the entire compression job can happen on your own device.
A practical example: FileOnTap's free image compressor. It runs 100% locally in your browser, so your files never leave your device. No upload queue, no account, no waiting on a server, and no privacy tradeoff — your photos stay yours. You drop in a PNG or JPEG, adjust the quality slider, preview the result side by side, and download a much smaller file. Because everything happens client-side, it works offline once the page is loaded and handles large files without choking.
One more tip: downscale before you compress. If your blog displays images at 800px wide, resize to that first — serving a 5000px original wastes bandwidth no matter how well it's compressed, and downscaling alone can cut file size by 70% or more.
A workflow that actually works
- Size to the display slot. Resize to the dimensions you'll actually show (e.g., max 1600px wide for a hero image). No amount of compression fixes an oversized image.
- Pick the right format. JPEG or WebP for photos; PNG for sharp graphics, screenshots with text, or anything needing transparency.
- Compress lossy at 80–85 for photos. Check smooth gradients for banding and fine detail for smearing.
- Compare at 100% zoom before shipping. Flip between original and compressed — if you can't tell them apart, you're done.
- Repeat for every asset. Images are usually the single biggest contributor to page weight, so this loop pays off fast.
Done consistently, this workflow turns a 6 MB upload into a 300 KB file that looks identical on screen. That's faster pages, happier visitors, and lower hosting bills — all without installing anything or uploading a single file.
Disclosure: I'm the developer of FileOnTap.
Top comments (0)