DEV Community: Nawal Shrestha

Image Optimization for Core Web Vitals: Fix Your LCP

Nawal Shrestha — Sat, 24 Oct 2026 04:26:08 +0000

Image Optimization for Core Web Vitals: Fix Your LCP

You run Lighthouse on the homepage. The score lands at 47, painted in angry red. Largest Contentful Paint sits at 5.8 seconds, and when you dig into the trace, the culprit is embarrassing: a 2.1MB hero JPEG, served at full desktop resolution to a phone.

Welcome to image optimization core web vitals work: the unglamorous, high-leverage job of making your pictures weigh less. LCP is the most image-driven of the three Core Web Vitals, and images are almost always the heaviest thing on the page.

Unlike most Core Web Vitals guides, this one gives you concrete KB budgets per image type and a worked audit you can repeat in DevTools. I build SnapShrink, a 100%-in-browser image compressor, so shrinking pictures is quite literally my day job.

Why LCP is usually an image problem

LCP measures when the largest visible element on screen finishes rendering, and on most pages that element is an image: a hero banner, a product photo, a featured post image. Text and CSS arrive in milliseconds, while a 2MB picture takes seconds on a mobile connection. Since Google wants LCP under 2.5 seconds, image weight is usually the whole battle.

Here is the math that makes it obvious. The HTML, CSS, and fonts on a typical marketing page weigh 100 to 300KB combined. One unoptimized hero image can weigh ten times that. The LCP element has to download, decode, and paint before the metric stops, so every extra megabyte stretches the timeline on a real mobile connection. Shrink the image and the metric usually follows.

Find your LCP image in under two minutes

Open Chrome DevTools, run Lighthouse from the Performance panel, and open the generated report. Scroll to the LCP element in the diagnostics section and click it; DevTools highlights the exact image on your page and shows its size and format. Note the file weight and the rendered dimensions, because the gap between the two is where your savings live.

The routine, step by step:

Run Lighthouse on the page with mobile emulation on. The default settings are fine; you want the same conditions Google scores.
In the report, find "Largest Contentful Paint element" under Diagnostics and click it. DevTools jumps straight to the image in the Elements panel.
Compare natural and rendered dimensions. If the file is 2400 pixels wide but renders at 390, you are shipping six times the pixels anyone sees.
Cross-check in the Network tab: filter by Img, sort by Size, reload with the cache disabled. The heaviest files float to the top, and the LCP image is usually one of the first three rows.

Set a KB budget before you touch a codec

Every image optimization core web vitals project I have run started with a budget, not a compressor. Decide the file size each image type is allowed before you touch anything: hero images get 150KB on desktop, 80KB on mobile; thumbnails get 30KB; avatars and icons get 15KB or ship as SVG. A budget turns optimization into a number you can verify.

Image type	Desktop budget	Mobile budget
Hero / banner	150KB	80KB
Product / feature shots	100KB	60KB
Card thumbnails	30KB	30KB
Avatars / icons	15KB (or SVG)	15KB (or SVG)

These are the ceilings I start from. They assume photographic content saved as WebP at quality 75 to 85. Illustrations and screenshots with flat colors compress far better, so treat the numbers as ceilings to stay under. If you like working backwards from the number, you can compress an image to an exact KB target in the browser instead of guessing at quality sliders.

The re-encode walkthrough: 2.1MB to about 110KB

Take the 2.1MB hero from our Lighthouse trace: a 2400x1600 JPEG served to every device. Resize it to the largest width the layout actually renders, 1600 pixels here, re-encode it to WebP at quality 80, and the file drops to roughly 100 to 140KB with no visible difference on screen. That single change typically cuts LCP by two to four seconds on a mobile connection.

The loop, in order:

Resize to the rendered width first. If the layout never shows the hero wider than 1600 pixels, a 2400-pixel source is pure wasted bytes. Resizing is the cheapest win in the whole process.
Pick WebP as your default. For photographic content it typically cuts 25 to 35 percent off an equivalent-quality JPEG. Keep the JPEG only if you still support truly ancient browsers; everything modern renders WebP.
Set quality between 75 and 85. Below 75, banding creeps into skies and gradients. Above 85, the file size climbs fast for differences nobody can see. I default to 80 and adjust by eye.
Compare the result against the original at 100 percent zoom. If you cannot spot the difference on a careful look, your users will not spot it at all. Ship it.
Re-run Lighthouse. The LCP number should move a lot. If it barely budges, the LCP element was not the file you optimized, and the audit in the second section sent you to the wrong image.

I built SnapShrink's free browser-based image compressor for exactly this loop: drop in the hero, resize, pick WebP, and everything re-encodes on your machine with nothing uploaded.

Your image optimization core web vitals questions, answered

Three questions come up every time image optimization core web vitals work lands on a developer's desk: whether lazy loading fixes LCP, whether AVIF is worth the hassle, and whether compression or responsive images matter more. Here are the short answers, with the tradeoffs that change the decision in practice.

Will lazy-loading the hero fix my LCP?

No. It usually makes LCP worse. Lazy loading defers offscreen images, but the LCP image is on screen by definition, so you would be adding delay to the exact thing you are trying to speed up. Mark the LCP image with fetchpriority="high", consider a preload link for it, and lazy-load everything below the fold. Google's guide to optimizing LCP walks through prioritizing the LCP element in detail.

Is AVIF worth switching to?

Not as your first move. AVIF typically shaves another 15 to 25 percent off WebP at matched visual quality, but encoding is slower and the tooling is thinner. Nail WebP first; add AVIF later.

Compression or responsive images: which first?

Compression first, responsive images second. Re-encoding one hero from JPEG to WebP can remove 70 to 90 percent of its weight in ten minutes. Responsive images with srcset and sizes stop you shipping desktop pixels to phones, which matters, but it is a code change across templates. Do the quick win this afternoon; schedule the srcset work for the sprint.

Back to that homepage scoring 47. Find the LCP image, give it a KB budget, re-encode it, and run Lighthouse again. LCP should drop hard, and the score usually follows it into the green. One page, one image, one afternoon.

WebP vs PNG vs JPEG: Which Format Should You Serve in 2026?

Nawal Shrestha — Wed, 21 Oct 2026 04:38:16 +0000

WebP vs PNG vs JPEG: Which Format Should You Serve in 2026?

Last week I ran SnapShrink's batch converter over a folder of 200 demo images for the tool's gallery. One PNG screenshot went in at 412 KB and came out at 96 KB as WebP. Same pixels, no visible difference. That folder is why I stopped treating webp vs png as a taste question. It's arithmetic now. Here's how I decide what to serve.

WebP vs PNG: how much smaller is WebP, really?

WebP is consistently smaller than PNG. Google's published WebP study measured lossless WebP at roughly 26% smaller than equivalent PNG files, and lossy WebP at 25 to 34% smaller than JPEG at comparable visual quality. Savings vary by image, but for anything served on a website, WebP almost always wins on size.

The catch is that WebP has two modes and they behave very differently. Lossy WebP is what you want for photos. Lossless WebP is what you want for screenshots, logos, and anything with text or hard edges. Mixing them up is the most common mistake I see. Lossy on a screenshot smears the text; lossless on a photo wastes bytes for detail your eyes can't see.

One honest caveat from building a converter: for very tiny or simple images, WebP's container overhead can wipe out the compression gain, and I've seen small icons where PNG came out ahead. Spot-check your own assets instead of trusting a rule.

WebP vs PNG for transparency and animation

WebP supports 8-bit alpha transparency and animation, so it covers every job PNG does except one: legacy compatibility. PNG still wins when the destination app only reads PNG, like some email clients, design tools, and old CMS pipelines. For animation, WebP beats GIF on file size, but actual video formats beat both WebP and GIF by a wide margin.

Transparency is the feature that made me stop defaulting to PNG. Early WebP had a reputation for rough alpha edges, but modern encoders handle it fine, and the files are much smaller. The one failure mode I watch for: converting a PNG with semi-transparent pixels and not checking the result. Alpha is the one thing that can break silently, so I always eyeball the converted file against a dark background.

For animation, WebP is technically fine and far smaller than GIF, but the authoring and tooling ecosystem never caught up. Short looping clips belong in muted MP4 or WebM. They compress better than any image format and browsers play them natively.

Where JPEG still beats both

JPEG wins on universal compatibility and encoding speed, not quality per byte. Every device built in the last twenty years reads JPEG, and encoding is instant. For photos served to old email clients, RSS readers, or user-uploaded avatars you don't control, JPEG at 80 to 85 quality remains the safe pick.

JPEG also has no alpha channel and no lossless mode, so don't force it into jobs it can't do. Text screenshots saved as JPEG get that familiar smudged look around every letter, which is why it's the wrong tool for UI images. Use it for photos aimed at destinations you can't control, and use WebP or PNG for everything else.

The 2026 decision framework I actually use

My rule is deliberately boring: photos and screenshots go to WebP, lossy for photos and lossless for anything with text or hard edges, with PNG reserved for tools that force it and JPEG for photos aimed at destinations I can't control. Everything gets wrapped in a picture element so the browser picks the best format it understands.

The picture element does the heavy lifting, so your markup doesn't have to guess:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Product dashboard screenshot" width="1200" height="630" loading="lazy">
</picture>

Browsers read the sources top to bottom and take the first format they support. Old browsers fall through to the JPEG. You can add AVIF at the top of the stack later without touching anything else, which is exactly how I future-proofed the SnapShrink gallery.

Situation	Serve this	Why
Photo on a modern site	WebP lossy, ~75-82 quality	Smallest file at good quality
Screenshot, logo, UI with text	WebP lossless	Sharp edges, alpha support, far smaller than PNG
Destination only accepts PNG	PNG	Compatibility beats bytes
Photo for email, RSS, unknown clients	JPEG, 80-85 quality	Universal support, instant encode
Short looping animation	Muted MP4/WebM	Beats every image format on size
Simple icon	SVG, or PNG if raster	Vector scales; PNG is the safe raster

How to convert without breaking things

Convert originals to WebP at build or upload time, never by hand-editing files on a live server. Keep your PNG masters archived for anything an external tool might need later, and always check alpha channels after conversion, since a broken alpha channel fails silently and looks terrible on dark backgrounds.

If you want the full file-size numbers and the technical background in one place, I've written a deeper WebP vs PNG comparison on the SnapShrink blog. And for the reverse trip, when some tool insists on a PNG, SnapShrink's free WebP to PNG converter handles the conversion in your browser with no upload.

Two practical gotchas before you convert a whole library. First, social and chat link previews still prefer JPEG or PNG for og:image, so don't WebP your share images. Second, WebP doesn't magically fix a bad source: a blurry JPEG converted to WebP is a small blurry image. Start from the highest-quality original you have.

FAQ

The short version of everything above: serve WebP by default, keep PNG for compatibility, use JPEG for photos aimed at old clients, and try AVIF behind WebP in your picture element if you feel like experimenting. The questions below cover the edge cases I get asked most.

Is WebP always smaller than PNG?

No. For most web images, yes, and usually by a lot. But for very small or very simple images, WebP's container overhead can eat the gain, and PNG sometimes comes out ahead. Test your own assets instead of trusting a blanket rule.

Should I convert my entire PNG library to WebP?

Only the files you actually serve on the web. Keep PNG masters archived. Re-converting from a lossy WebP back to PNG later is a one-way trip you don't want to take.

What about AVIF?

AVIF typically compresses 20 to 30% smaller than WebP's lossy mode, but encoding is noticeably slower and tooling support is still catching up. It's worth trying behind a picture element where WebP is the fallback. Don't rebuild your whole pipeline around it yet.

Does WebP work in every browser?

All modern browsers have supported WebP since around 2020, including Safari from version 14. The picture element pattern above covers the stragglers with a JPEG fallback, so browser support shouldn't stop you.

Remember that 412 KB screenshot from the demo folder? It shipped as a 96 KB WebP and nobody noticed except me, checking the network tab. That's the whole pitch. Pick WebP as your default, keep PNG and JPEG for the jobs they still own, and let the picture element sort out the rest. Your users' bandwidth will thank you.

JFIF to JPG, WebP to GIF, HEIC to PNG Explained

Nawal Shrestha — Sat, 17 Oct 2026 04:26:34 +0000

JFIF to JPG, WebP to GIF, HEIC to PNG: Three Conversions That Confuse Everyone

You hit Save, and instead of photo.jpg you get photo.jfif. The upload form rejects it. You stare at the extension like it personally wronged you.

I build SnapShrink, a browser-based image tool, so I collect these moments. That .jfif confusion is one of three format conversions that trip up basically everyone. The other two: a WebP animation the platform won't accept, and iPhone photos that won't open on Windows. Here's what each one actually is, and the fastest way through it.

1. JFIF to JPG: the format you've used without knowing

If you've ever saved an image and gotten a .jfif file instead of .jpg, you've met JFIF. Despite the unfamiliar extension, it's a JPEG under the hood — JFIF (JPEG File Interchange Format) is just a slightly different container for the same data. Your camera, your phone, and half the software on your computer treat them as the same thing.

The problem is the other half. Some upload forms, older editors, and picky CMS platforms reject .jfif outright because the extension isn't on their allowlist. The file is fine; the extension is the problem.

The fix takes seconds: converting JFIF to JPG just rewrites the container, no recompression, no quality loss. I run a free JFIF to JPG converter for exactly this — drop the file in, get a .jpg back, upload wherever you were blocked.

2. WebP to GIF: when you need the animation, not the efficiency

WebP is the better format on paper. Smaller files than JPEG, supports transparency like PNG, and handles animation too. Google's been pushing it for a decade and browsers finally all support it.

But "better on paper" doesn't matter when the tool on the other end doesn't accept it. Email clients, some chat apps, forum software from 2015, design tools with frozen feature sets — plenty of places still only speak GIF for animations. I hit this making demo clips: record as WebP, then discover the platform I'm posting to wants GIF.

Converting WebP to GIF re-encodes the animation frames. Quality takes a small hit (GIF is limited to 256 colors per frame), so keep the source WebP archived. For the actual conversion I use an in-browser WebP to GIF tool — nothing uploads anywhere, which matters when the clip is client work.

3. HEIC to PNG: iPhone photos on a Windows machine

This is the one that generates the most confused messages. You AirDrop or transfer photos from an iPhone to a Windows PC, and half of them won't open. Those are HEIC files — Apple's default photo format since iOS 11. It's genuinely good tech (about half the file size of JPEG at the same quality), but Windows support is still patchy in 2026.

PNG is the safe target here, not JPG. If you're pulling photos off a phone to edit or archive, PNG keeps every pixel — no generational loss on top of whatever the phone already did. JPG is fine for sharing; PNG is right for keeping.

The conversion is straightforward with a HEIC to PNG converter. One thing to watch: HEIC files sometimes contain multiple images (bursts, live photo frames). A decent converter handles the primary image; if you need every frame of a burst, that's a separate job.

A note on where the conversion happens

All three tools I linked above run entirely in your browser. Most people never check this: the majority of "free online converters" upload your file to a server, convert it there, and hand it back. For a meme, who cares. For client photos, unreleased product shots, or anything with people in it, that upload is a privacy decision you're making without realizing it.

You can verify the browser-only claim yourself in about ten seconds: open DevTools, go to the Network tab, run a conversion. If the network stays quiet, the file never left your machine. I built SnapShrink this way because I got tired of wondering where my files went.

The short version

JFIF → JPG: same image, friendlier extension. Container swap, zero quality loss.
WebP → GIF: for the platforms stuck in 2015. Real re-encode, keep your source.
HEIC → PNG: iPhone photos on Windows. PNG for archiving, JPG for sharing.
Check where conversion happens before uploading anything you wouldn't post publicly.

Three conversions, three tools, no accounts, no uploads. And next time a save dialog hands you a .jfif, you'll know exactly what it is — and exactly where to take it.

I compared TinyPNG alternatives on privacy, not just file size

Nawal Shrestha — Wed, 07 Oct 2026 16:15:41 +0000

Everyone's used TinyPNG. It's the default "make this image smaller" tool, and its compression is genuinely good. But every roundup I read compares these tools on file size alone, and in 2026 that's the least interesting difference between them.

Here's the direct answer: the tools differ less on file size than on where your images get processed and what you pay. TinyPNG uploads your files to its servers and charges a subscription (Web Pro is $3.25/month billed annually — $39/year, verified on their pricing page today). Browser-local tools like Squoosh and SnapShrink process everything on your device. I build SnapShrink, a batch image compressor that runs 100% in the browser, and I'll tell you exactly where TinyPNG still wins. If you handle client photos, ID scans, or unreleased work, the privacy angle matters more than a 5% size difference, and almost nobody writes about it.

The comparison that actually matters

	TinyPNG	Squoosh	SnapShrink	Compressor.io
Where files are processed	Their servers	Your browser	Your browser	Their servers
Free batch limit	20 images, 5 MB each	1 image at a time	10/session, no file cap	~10/session
Pricing	Free tier + Pro/Ultra subscriptions ($39/year Pro)	Free forever	$9 one-time	Free tier + subscription
API / WordPress plugin	Yes, mature	No	No	No
Target an exact file size	No	No	Yes (type the KB)	No
EXIF stripped	Server-side	N/A (local)	On-device, automatic	Server-side

TinyPNG's free tier is honest: 20 images at once, 5 MB each. The paid product is a subscription — $39/year for Web Pro, $149/year for Ultra. That's a fine model for a server-side tool, because bandwidth and compute cost real money per image. It's just worth asking whether your use case needs a server at all.

How does in-browser compression actually work?

No magic, and no server: the browser reads your files with the File API, encodes them in a Web Worker (so the tab stays responsive), and hands you the bytes back. The network is never involved — your CPU does the work your laptop was already going to do.

The quality difference people worry about is real but small. Browser canvas encoders are a bit less efficient than TinyPNG's proprietary quantizer at maximum compression, but encoder choice matters less than your settings. On a 3000×2000 test photo I measured, JPEG quality 80 came out ~42% smaller than quality 95 with no visible difference at normal viewing distance — and switching the same photo to WebP at quality 80 cut the file to less than half the JPEG. Quality level, dimensions, and format dwarf the tool-to-tool gap.

How can you verify a compressor really keeps your files local?

Don't trust privacy policies — test them. This 30-second check works on every compressor on the market, including mine:

Open any compressor, press F12 → Network tab.
Drop in photos, compress.
Filter for uploads (POST/PUT with file bodies).

With a browser-local tool you'll see zero — because there are none to see. Run the same test on a server-side compressor and watch the difference.

There's a second angle nobody mentions: EXIF data. Phone photos carry GPS coordinates, timestamps, device info. Upload that to a server compressor and the metadata travels with the file — you're trusting their pipeline to strip it. Local tools strip it on your device before anything could leave. (I wrote up why that matters separately.)

When should you stick with TinyPNG?

Plenty of cases where I'd pick TinyPNG myself:

You need compression inside an automated workflow — build pipeline, CMS, upload endpoint. TinyPNG's API is built for exactly that; browser tools are manual.
You use the WordPress plugin. Mature, set-and-forget.
You want their specific PNG quantization. For aggressive PNG size reduction it's still excellent.
You're compressing 1–5 images occasionally and don't care about uploads or subscriptions.

The honest version: these tools overlap but aren't identical. TinyPNG has the ecosystem. Browser-local tools have the privacy model and (in our case) the pricing model.

Why can a browser tool charge $9 once while TinyPNG charges $39/year?

Because the cost structures are completely different. Server-side tools pay for bandwidth and compute on every single image — subscriptions make sense for them. A browser tool's marginal cost per image is ~zero after the page loads, so charging monthly rent for it is a business choice, not a technical necessity.

That's the whole argument for $9 once: pay through Dodo Payments, get a license key by email, paste it in, done. Offline verification, no account, 14-day money-back guarantee.

Limitations, stated plainly: no API, no WordPress plugin, no AVIF output in v1, 10 free images per session. If any of those are your workflow, TinyPNG or Squoosh is the better pick.

FAQ

Is SnapShrink actually free?

The first 10 images per session are free, no account needed. After that it's a $9 one-time payment for unlimited use — not a subscription. There's a 14-day money-back guarantee, and the license is verified offline, so the tool keeps working even without an account system.

Does browser compression match TinyPNG's quality?

Close enough that your settings matter more than your tool. TinyPNG's quantizer has a small edge on maximum PNG compression, but quality level, dimensions, and format choice (especially WebP) move file size far more than encoder choice. My own test: JPEG quality 80 vs 95 on the same photo — 42% smaller, no visible difference.

What happens to EXIF data in my photos?

It's stripped on your device, automatically, before anything could leave — because nothing ever leaves. With server-side compressors, your GPS coordinates and timestamps travel with the upload and you're trusting their pipeline to strip them. I wrote a separate guide on stripping metadata from photos if you want the full picture.

Can I hit an exact file size, like under 100KB?

Yes — that's the one thing most compressors can't do. Instead of guessing the quality slider, you compress an image to an exact file size by typing the target KB, and the tool finds the quality setting that fits at or under it.

The longer version with the full comparison table and decision matrix lives on the blog: TinyPNG Alternative You Pay Once ($9). Try the tool free — getsnapshrink.com/app.

Stop Guessing the Quality Slider — Binary-Searching JPEG Quality for Exact File Sizes

Nawal Shrestha — Tue, 06 Oct 2026 12:19:43 +0000

Here's a UX problem every image tool punts on: the user doesn't want "quality 80". They want "under 100KB" — because a form said so. The quality slider is the tool's internal machinery exposed as UI. Users shouldn't have to learn your encoder's quality curve.

In SnapShrink I built Target KB mode: type 20, get a file at or under 20KB. Here's the approach.

The algorithm

It's a binary search over the quality parameter:

Set bounds: quality 1–100 (or your encoder's range).
Encode at mid quality, measure the output bytes.
If over target, search the lower half; if under, search the upper half — keeping the best valid result.
~7 iterations converges. Each iteration is a fast in-memory encode; no network involved.

The key detail: quality is searched first, dimensions last. Only if quality=1 still overshoots do you downscale slightly and re-run the search. Most photos hit common caps (20/50/100KB) with dimensions untouched, which is what users expect — they asked for a size, not a resize.

Why this matters more than it sounds

Government and exam portals (India's UPSC forms: 20–300KB caps) reject oversized uploads with zero guidance. "Type the number" beats a slider every time.
It composes with batch: set the target once, every file in the batch gets its own binary search, download as ZIP.
It works client-side. The encodes are cheap enough to run in a Web Worker without blocking the page.

The honest edge cases

Tiny targets on huge photos will visibly degrade — that's physics, not a bug. Showing the achieved size when the target is unreachable beats silently overshooting.
PNGs with sharp text compress differently than photos; the search handles both because it measures actual bytes, not estimates.

If you maintain an image tool, consider exposing the target instead of (or alongside) the slider. Users think in file sizes. Meet them there.

Live at getsnapshrink.com/compress-image-to-exact-kb/ — first 10 images per session free, everything runs in the browser. The same engine also powers HEIC→JPG and AVIF→JPG conversion — new input formats turned out to be just a decode step.

I Added Client-Side HEIC to JPG Conversion to My Image Tool — No Server, No Upload

Nawal Shrestha — Tue, 06 Oct 2026 12:18:07 +0000

Most "free HEIC to JPG" tools work the same way: you upload your iPhone photos to someone's server, it converts them, you download the result. For a format conversion — one of the most local operations imaginable — that's a strange trade.

I wanted HEIC to JPG support in SnapShrink (my in-browser batch image compressor) without breaking its core promise: nothing ever uploads. Here's how I did it.

The decoder: heic2any, lazy-loaded

Browsers can't decode HEIC natively (unlike AVIF, which Chrome/Edge/Firefox handle via createImageBitmap). So the conversion needs a real decoder. I used heic2any, pinned to a fixed version, loaded via dynamic import() only when a HEIC file is actually dropped.

That last part matters: the decoder is a chunk of WASM/JS you don't want in the initial bundle for the 95% of users who never touch HEIC. Lazy-loading keeps the first paint fast for everyone.

The pipeline

Once decoded, a HEIC file is just pixels — it flows into the exact same pipeline as every other format:

Decode → ImageData/canvas
Quality slider or Target KB mode (binary-search the quality setting until the output fits)
Encode to JPG/PNG/WebP, batch, ZIP download

No HEIC-specific special cases downstream. That was the whole point of the architecture: new input formats are a decode step, not a new app. AVIF support later followed the same path — same idea, native decode.

The UX details that matter

Files get a small "HEIC" badge in the drop list so users can see what was detected.
A misnamed file (.heic that's actually a JPEG) gets a clear error instead of a cryptic decoder failure.
Target KB mode works on HEIC too — type 100, get ≤100KB. This is the feature people actually write in about: forms with hard size caps. (How it works.)

Try it

Drop a real iPhone photo on getsnapshrink.com/heic-to-jpg/ and watch DevTools → Network while it converts. Zero file uploads — that's the entire architecture, and HEIC didn't change it.

First 10 images per session free, unlimited is a one-time $9. Happy to answer questions about the implementation in the comments.

Compress Image to 100KB Online — No Upload

Nawal Shrestha — Sun, 04 Oct 2026 03:58:14 +0000

Visa portals, exam forms, and job applications all ask for the same thing: a photo under 100KB. Most compressors hand you a quality slider and wish you luck — you export at 60%, check the size, re-export at 50%, check again. Five guesses later you land at 97KB with a photo that looks worse than it needed to.

There's a better way: name the size, and let the tool find the best quality that fits it. Type 100, get ≤100KB, done — with your file never leaving your device.

Why 100KB limits are everywhere

Government and university portals process millions of files. A hard per-file cap keeps storage costs and database rows predictable. A phone photo today is 3–8MB, so "under 100KB" means shrinking it to roughly 2% of its original size.

Common places you'll hit this limit:

Visa and passport applications — photo and signature uploads, often capped at 100KB or even 50KB
Exam and university admission portals — scanned documents and photos with per-file caps
Job applications — resume portals that reject oversized profile photos
Scholarship and KYC forms — ID scans that must stay small but readable
Banking portals — document uploads for account opening or loans

The cap persists because the bottleneck is storage and database row size, not your internet speed. Faster broadband didn't move it; it won't move soon.

What 100KB actually looks like: quality vs size

People imagine 100KB means a ruined photo. It depends entirely on dimensions. Here's the relationship, roughly, for a typical phone photo saved as JPEG:

Source dimensions — Quality 85 — Quality 60 — Quality 40
4000×3000 (12MP) — ~2.5 MB — ~1.2 MB — ~600 KB
2000×1500 — ~700 KB — ~350 KB — ~180 KB
1200×900 — ~280 KB — ~140 KB — ~75 KB
800×600 — ~130 KB — ~65 KB — ~35 KB
Illustrative — actual sizes vary with image complexity. Noisy, detailed photos run heavier.

The takeaway: 100KB is mostly about resolution, not the quality slider. A 1200×900 photo at quality 60 hits ~140KB; drop to 800×600 and you're comfortably under 100KB at decent quality. Anyone telling you to "just lower the quality" on a 12MP original is giving bad advice — resize first, then compress.

Type 100, get ≤100KB: how target-size mode works

In SnapShrink you type 100 into the target-size box and the engine does the search for you:

Drop your image at https://getsnapshrink.com/app/. JPG, PNG, WebP, and GIF accepted.
Type 100 as the target size in KB and pick your output format (WebP is smallest for photos — but check portal acceptance below).
Binary search on quality. The engine encodes at quality 95, then 50, then narrows the range — about 8 encodes — to find the highest quality that lands at or under 100KB.
Downscale fallback. If even quality 5 overshoots, the image scales down in ×0.9 steps (never below 320px) and the search repeats.
You get the result with before/after sizes shown. On the rare image where 100KB is truly unreachable, it reports the best effort it managed instead of failing silently.

It all runs in a background worker in your browser tab, so the page stays responsive. A standard 5MP phone photo typically finishes in under 3 seconds.

Which format will the portal accept?

This is where people get burned. You compress a beautiful 80KB WebP, upload it, and the portal rejects it — not for size, but for format. Older government and banking portals often accept only JPEG (sometimes only JPG, not even PNG).

Your image — Best format — Why
Photo / camera shot — WebP or JPEG — Smallest at a given quality; WebP usually wins ~25%
Screenshot / graphic with text — PNG or WebP — Keeps edges sharp
Scan of a document — WebP or JPEG — Text stays readable far below 100KB in grayscale
Signature on white background — PNG or JPEG — Tiny anyway; JPEG safest for old portals
Rule: when in doubt, JPEG. It's the universally accepted format. Use WebP only when you've confirmed the portal takes it — or when the file is for your own site, not someone else's form.

Compress a batch to 100KB

A passport photo, a signature scan, a supporting ID — drop them all at once. SnapShrink's bulk image compressor (https://getsnapshrink.com/bulk-image-compressor/) applies the 100KB target to each file individually, because every image needs a different quality level to hit the same cap. When the batch finishes, download everything as one ZIP.

This beats the one-by-one loop most online tools force on you, and it eliminates the rename-and-organize step — the ZIP keeps your filenames.

Compressing from a phone

Identical process in Safari on iOS and Chrome on Android: tap the drop zone, pick from camera roll or files, type 100, download. The file lands in Downloads, ready to attach.

One iOS wrinkle: phone photos are typically HEIC. Safari converts HEIC to JPEG automatically through the file picker, so SnapShrink receives a JPEG and processes it normally. No manual conversion needed.

Why "no upload" matters for document compression

Passport photos, ID scans, and visa applications contain biometric data. Uploading those to a third-party compressor — even one promising deletion — creates a data trail: how long the server actually retains the file, who can access it, what their breach notification obligations are. You have no visibility into any of that.

SnapShrink processes images with the browser's Canvas API and a Web Worker. The bytes never leave your device.

Verify it yourself — don't take my word for it:

Open the tool (https://getsnapshrink.com/app/) and press F12 → Network tab.
Compress a photo.
Look for file uploads in the network log.

There are none. Thirty seconds, and you've confirmed what no privacy policy can prove for a server-side tool. For documents this sensitive, "trust us" isn't good enough — testable beats promised.

SnapShrink also strips EXIF metadata (GPS coordinates, device info, timestamps) automatically during compression. Your ID photo shouldn't ship your location history to a portal database.

Step by step: compress to 100KB

Open the SnapShrink tool (https://getsnapshrink.com/app/) — no signup, no install.
Drag in your photo (or pick files with the button).
Type 100 in the target-size field. Choose JPEG if the portal is old or unspecified; WebP if confirmed accepted.
Hit Compress, then download. The file is ≤100KB and ready for the portal.

First 10 images per session are free. If you process documents regularly, one $9 payment unlocks unlimited use — no subscription.

Troubleshooting: when the image won't reach 100KB

Genuinely impossible cases are rare but real. A 320×320px photo that's already 110KB at quality 1 in JPEG has nowhere left to go. In that situation:

Switch to WebP — usually smaller than JPEG at the same dimensions (if the portal allows).
Crop tighter — border whitespace costs bytes, especially in JPEG.
Resize to the portal's minimum — if it says "minimum 200×200px", try exactly 200×200.
Grayscale for documents — some portals accept it, and it compresses far more efficiently.
Check the EXIF — a 50–200KB metadata payload on an unprocessed phone photo is dead weight; stripping it alone can close the gap.

SnapShrink always reports the actual output size, so you know exactly where you stand instead of guessing whether a rejection was the size, the format, or the portal being slow.

FAQ

Is my photo uploaded to a server?
No. Compression happens entirely in your browser. Open DevTools → Network while compressing — zero file uploads. That's the whole point.

What if my image can't reach 100KB?
Rare, but possible with very detailed images at small dimensions. You'll see the smallest size achieved ("best effort") instead of a silent failure.

Which browsers work?
Chrome, Edge, Firefox, and Safari handle WebP encoding natively. If yours can't encode WebP, the tool says so and you pick JPEG or PNG instead.

Is there a file size limit?
Files up to 50MB accepted. Larger files are skipped with a clear message; the rest of the batch keeps going.

Can I compress multiple images to 100KB at once?
Yes — drop the batch, set the target once, download a ZIP. Each image is processed individually to hit the same cap.

JPEG or WebP for a 100KB target?
WebP preserves more quality at 100KB, but old portals may reject it. JPEG when unsure; WebP when confirmed.

How is this different from Squoosh?
Squoosh is excellent for single-image manual tuning. SnapShrink is built for two things Squoosh doesn't do: batch processing and target-size mode — type the cap, get there automatically. One image with pixel-perfect control: Squoosh. A stack of documents with a size cap: SnapShrink.