Why I built this
I had to upload product photos to my Etsy store in May 2026 — Etsy caps each image at 10 MB but my iPhone shoots HEIC files at 4-6 MB that, after auto-conversion to JPEG by my Mac, balloon to 12+ MB. The first three "image compressor" sites I tried wanted me to either sign up or upload my product photos to their servers. One added a faint "compressed by FreeImage.com" watermark across the bottom corner of every image. A second site only let me compress 5 images before locking the rest behind a $7.99/month paywall. A third advertised "free unlimited" but logged my image to a server in Singapore visible in the Network tab — exactly what I was trying to avoid.
What really bothered me was the privacy angle for 당근마켓 / Carrot listings. Korean second-hand marketplaces auto-attach iPhone EXIF data (which includes precise GPS coordinates from where the photo was taken — often your home) unless you strip it. The "free image compressors" all forwarded EXIF intact, meaning my apartment's location was sitting in some random server's logs.
OhMyIcon Compressor runs in your browser via the Canvas API — the same drawing primitive every browser ships natively. There is no upload, no signup, no watermark, no monthly cap. Format conversion is bundled in: convert HEIC, PNG, or older JPEG to modern WebP at the same compression step. EXIF metadata is stripped automatically as a side effect of canvas re-encoding, which is a privacy win for marketplace photos.
How it works under the hood
When you drop an image, the browser reads it into an Image element via URL.createObjectURL() — a purely in-memory operation. The image is drawn onto an off-screen HTMLCanvasElement at the requested dimensions (the canvas API does the pixel resampling using a Lanczos-like algorithm built into the browser). Then canvas.toBlob(callback, mimeType, quality) re-encodes the canvas pixels into the target format. The resulting Blob is offered as a download.
The quality slider is passed directly to the encoder. For JPEG, quality maps to the standard JPEG quality factor (0-100, where 90 is near-lossless and 60 is web-thumbnail quality). For WebP, quality controls the trade-off between file size and PSNR (peak signal-to-noise ratio) — the encoder spends more bits preserving detail at higher quality settings. For PNG, quality is ignored because PNG is lossless.
The bottleneck is memory. The canvas holds the full uncompressed bitmap (width × height × 4 bytes for RGBA) plus a working buffer for the encoder. A 4000×3000 photo needs ~96 MB of RAM during processing. Older phones and tablets can run out of memory above ~15 MP — if processing fails silently, try resizing down first.
Verify yourself: open DevTools → Network tab, clear the log, drop an image, and click Compress. The list stays empty. No image bytes are sent over the network. Most hosted "free compressors" cannot make this claim because their backend algorithms run on a server somewhere — your image is the input.
Real use cases
- 당근마켓 / Carrot Market listings: Strip GPS-revealing EXIF before posting, resize to 1080px wide (the platform's native display size), and convert HEIC to JPEG since Carrot does not accept HEIC. Three problems solved in one tool.
- Etsy and Shopify product photos: Both platforms cap each image at ~10 MB. iPhone shots after HEIC-to-JPEG conversion often exceed this. Drop quality to 85% WebP and most images land at 200-400 KB without visible degradation.
- Email signatures and Gmail attachments: Embed a small logo (under 50 KB) so emails are not flagged as oversized. Compress a screenshot for a support ticket without filling the inbox.
- Job application headshots: Many ATS systems cap profile images at 2 MB. A modern phone photo is 4-8 MB raw, so compression is essentially mandatory. Skip the marketing-fluff resume sites and just shrink it here.
- Blog and portfolio image preparation: Convert 12 MB DSLR exports to 200 KB WebP files for fast page loads. Resize to actual display width (you do not need a 4K image for a 800px-wide blog post) to save additional bytes.
vs other image tools
How OhMyIcon Compressor compares to the most-Googled alternatives as of May 2026:
| Feature | OhMyIcon | TinyPNG | Squoosh | Compressor.io |
|---|---|---|---|---|
| Free tier | Unlimited | 500/month | Unlimited | Limited |
| No upload to server | Yes | No | Yes | No |
| No signup required | Yes | Yes | Yes | Yes |
| Format conversion | JPEG/PNG/WebP/AVIF | JPEG/PNG/WebP | All major | JPEG/PNG/WebP |
| Resize in same step | Yes | No | Yes | Limited |
| EXIF stripping | Yes (automatic) | Yes | Yes | Yes |
| Best on PNG photos | Good | Excellent (smart-lossy) | Excellent | Good |
| Source code inspectable | Yes | No | Yes (open source) | No |
Where competitors win: TinyPNG's proprietary smart-lossy algorithm produces 10-15% smaller PNGs than our Canvas re-encode in many cases — they have invested years in fine-tuning. Squoosh (built by Google Chrome team) is fully open source and offers more advanced format-specific knobs (MozJPEG, OxiPNG presets) for power users. Compressor.io has stronger compression on photos via server-side mozjpeg. For day-to-day work — shrinking a phone photo, converting HEIC, prepping for a marketplace listing — our combination of compression + resize + format conversion in one step is faster and equally private. For maximum compression with no privacy concern, Squoosh is a great free alternative.
What this can't do
- Smart-lossy PNG compression. TinyPNG's algorithm beats us on PNG by ~15%. Their secret sauce is proprietary palette reduction; we use stock Canvas re-encoding.
- Preserve EXIF metadata. Canvas re-encoding drops it. This is usually a feature (privacy) but if you need EXIF preserved for archival purposes, use exiftool or a desktop tool.
- Process animated GIFs. Canvas reads only the first frame. Use OhMyGIF for animated formats.
- Batch process. One image at a time. For 50+ files, a desktop tool (ImageMagick, libvips, Squoosh CLI) is more efficient.
- Handle files over 25 MB or 50 MP. Browser memory caps make larger images unreliable. Mobile browsers cap lower (~10-15 MB).
- RAW format support (CR2, NEF, ARW). Browsers do not decode RAW. Convert with your camera software or Lightroom first.
If you need maximum compression at any cost, run Squoosh + a desktop tool like cavif for AVIF or pngquant for PNG. For batch work, ImageMagick is the swiss-army knife.
Format guide
- WebP — Best general default. 25-35% smaller than JPEG. Universal browser support since 2024.
- JPEG — Use for email signatures, legacy systems, anywhere photographs need to render in 20-year-old software.
- PNG — Lossless. Use only when you need transparency without WebP, or when text/UI screenshots must be pixel-perfect.
- AVIF — Newest. ~20% smaller than WebP at the same quality. Encoding requires Chrome 85+ or Safari 16+.
Quality cheat sheet
- 95%: archival, virtually no compression artefacts
- 85%: print quality, indistinguishable from source for photos
- 80%: web default — invisible loss for most photos
- 60%: web thumbnails, social media previews
- 40%: aggressive compression for low-bandwidth previews
Tips for best results
Resize before compressing for screen use. If your blog displays images at 800px wide, do not upload a 4000px-wide photo at 80% quality — resize to 1200px first (2× for retina), then compress. The savings compound: resize cuts ~80% of pixels, compression then cuts another 60% of remaining bytes.
Convert HEIC iPhone photos to WebP directly. Skip the intermediate JPEG step that adds an unnecessary re-encode. Drop the HEIC, choose WebP output, set quality to 85%.
For screenshots, use PNG-to-WebP, not PNG-to-JPEG. JPEG ruins screenshot text (chroma subsampling blurs sharp edges). WebP handles both photo and UI content gracefully.
Test your quality setting on one image first. Different image content tolerates different compression levels. A landscape photo looks fine at 60% quality; a complex pattern with fine detail needs 85%+. One trial run saves time on a batch.
FAQ
How does this differ from TinyPNG? TinyPNG is excellent but uploads your image to their server and limits you to 500 images per month on the free tier. They use a proprietary smart-lossy algorithm that often beats our Canvas-based output by 10-15% on PNG. The trade-off is privacy and quota. OhMyIcon Compressor runs entirely in your browser using the Canvas API, so there are no uploads, no monthly caps, and no account. You also get more controls (format conversion, quality slider, resize) in one step. For private product photos or screenshots, we are the safer pick; for absolute smallest PNGs at scale, TinyPNG still wins.
Which format should I pick? WebP for general web use — it is supported by 97%+ of browsers in 2026 and produces 25-35% smaller files than JPEG at equivalent quality. JPEG when you need maximum compatibility (email signatures rendered in 20-year-old Outlook, ancient legacy systems, printers without modern image decoders). PNG only when you need lossless or transparency without WebP. AVIF for the absolute smallest files (Safari 16+, Chrome 85+) — about 20% smaller than WebP but encoding takes 3-5× longer. For most "compress this photo to email it" use cases, WebP is the right default.
Why is my AVIF output not generated? AVIF encoding requires browser support that lags behind decoding. Chrome 85+ encodes; Safari 16+ encodes; Firefox supports decoding but encoding lands later than this writing. If your browser cannot encode AVIF, the canvas.toBlob call returns null and we surface a friendly error. Switch to WebP — it is almost as efficient, encodes 4× faster, and is supported everywhere. AVIF is the right choice when every byte matters (e-commerce hero images at scale) but for one-off images the speed/size difference is rarely worth the format hassle.
Why did my output get larger? You probably set quality higher than the source's effective quality, or you re-encoded an already-compressed image. Re-saving a 75%-quality JPEG at 90% quality grows the file because the encoder cannot reconstruct the discarded data — it just spends more bytes preserving the existing compression artifacts. Try lowering quality to match or slightly exceed the source. For already-optimized images from professional photographers or stock sites, accept that there is no win to be had and skip compression entirely.
Does compression work on animated GIFs? No. The Canvas API only sees the first frame, so an animated GIF will be flattened to a single still image. For animated GIF resizing or compression, use OhMyGIF (our sister site) — it does proper frame-by-frame decoding with gifuct-js and re-encoding with gif.js, preserving all animation. Static GIFs work fine here but are usually better converted to PNG anyway, since GIF is limited to a 256-color palette.
How private is this really? The image is read with URL.createObjectURL and processed via the Canvas API — both operate entirely in memory. There is no fetch() call to any server. Open DevTools → Network tab, clear the log, and click Compress; you will see exactly zero outgoing requests carrying your image bytes. The only network activity is the initial page load (HTML, JS, CSS) which is cached after first visit. The image stays in your browser memory until you close the tab, at which point it is garbage-collected.
Why is the in-browser AVIF output sometimes worse than command-line cavif? Browser AVIF encoders prioritize speed over compression ratio. The Chrome implementation uses libaom with relatively conservative settings to keep encoding under a few seconds per image. Command-line tools like cavif or libheif-tools can spend 30+ seconds per image exploring more efficient encodings — usable for batch overnight processing but unacceptable for an interactive web tool. If you need the smallest possible AVIF, encode in-browser then run a desktop tool on the output for an extra 5-10% squeeze.
Can I batch-compress multiple images at once? Currently the tool processes one image at a time. Batch processing in-browser is technically possible but memory-intensive — each Canvas operation holds the full uncompressed bitmap in RAM (a 4000×3000 photo is ~48 MB uncompressed). For batches of 20+ photos at full resolution, a desktop tool like Squoosh CLI, ImageMagick, or libvips is more efficient. Single-image use covers the 90% case: shrinking one product photo, optimizing one screenshot, converting one HEIC.
Does this strip EXIF metadata? Yes. Canvas re-encoding drops all EXIF metadata including camera model, GPS coordinates, timestamps, and copyright. This is a privacy win — your iPhone photos no longer leak your home address through GPS coordinates when you share them online. If you need to preserve EXIF (for archival or legal reasons), the Canvas API simply cannot do it; use an EXIF-aware tool like exiftool. For posting product photos to Etsy, Carrot, or 당근마켓 without leaking location, the EXIF stripping is exactly what you want.
What is the maximum file size? 25 MB per image. The constraint is browser memory: a 25 MB JPEG decompresses to roughly 200 MB of raw RGBA pixels in canvas memory, and most browsers cap each tab around 2 GB of heap. Photos from a recent iPhone (5-12 MB HEIC, larger after conversion to PNG) fit comfortably. DSLR raw exports often exceed this — convert to a smaller format first with your camera software. Mobile browsers (especially Safari on iOS) have stricter memory limits and may fail at 15-20 MB.