Image Compressor

Image weight is the single largest determinant of how a modern web page feels. Google's own Core Web Vitals — Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint — are dominated by images on the vast majority of content pages, because images are usually the largest byte payload, the slowest to decode, and the part of the layout that most often shifts when it finally arrives. The same payload economics apply outside the browser too: a phone clip you want to email, a product photo a teammate needs in Slack, a portfolio image a client should be able to download over hotel Wi-Fi. Compression is the universal answer, and for years the most popular tool — TinyPNG — has held a near-monopoly because it gives non-engineers a way to compress without learning ImageOptim, jpegoptim, oxipng, sharp, or any other production-grade tool. The trade-off is that TinyPNG and most of its imitators upload your image to a server, run the compressor there, and email you the result.

This compressor is built for the same audience but does the work entirely in your browser. When you drop an image into the page, the file goes through three steps that all run inside the browser sandbox: the bytes are decoded into an in-memory bitmap, the bitmap is drawn to a canvas at the dimensions you choose, and the canvas is re-encoded to JPEG, PNG, WebP, or AVIF using the browser's built-in encoders. Nothing is uploaded. The Network tab shows zero outbound requests during compression — you can verify in DevTools, and you can even disconnect from the internet after the page loads and the tool will continue to work. For anyone working with sensitive material — customer photos, internal mockups, screenshots that contain confidential text, anything covered by an NDA — the privacy-first model is the only safe option.

Four input formats are supported: JPEG (the de facto standard for photographs since 1992), PNG (the universal format for graphics with transparency), WebP (Google's 2010 modern container that beats both on file size for almost all real images), and AVIF (the 2019 AV1-derived format that beats WebP at the same quality but encodes more slowly). For each input you can choose to keep the original format, which is the safest choice when you need backwards compatibility, or convert to a different format. The most common conversion in 2026 is PNG → WebP, which typically cuts size by 60–80% while preserving transparency, and JPEG → WebP, which adds another 25–35% saving on top of a typical photo. AVIF is the most aggressive choice — about 20% smaller than WebP for the same perceived quality — but encoding takes substantially longer in the browser and is only available in Chromium-based browsers as of late 2024.

The Quality control is the lever you reach for first. Internally it maps to the canvas encoder's quality parameter (0.0 to 1.0) and to the JPEG/WebP/AVIF quality scales (0 to 100), where 100 is essentially lossless and 0 is unrecognizable. The right number depends on what the image is for. Photographs published on the web look identical to the source down to about 78–82, which is the default this tool ships with — that is the same range YouTube ingestion targets, the same range Adobe's Save For Web defaulted to for two decades, and the range Google's WebP team recommends for general-purpose use. Marketing graphics with text or sharp edges should be set higher, around 88–92, because text in compressed images is the first thing the human eye notices. Thumbnails and avatars where the displayed size is small can go as low as 60–65 and remain perfectly fine. The slider lets you preview what each setting produces without leaving the page.

Target Size mode is the second mode, useful when you have a hard byte budget — for example, a CMS that rejects uploads above 500 KB, an email attachment limit of 25 MB, a chat platform that compresses anything over 200 KB. Target size mode runs a binary search over the quality parameter: it encodes at quality 67, checks the result size, encodes higher or lower depending on whether the result fits, and converges on the highest quality that fits in seven iterations. This is exactly the algorithm used by command-line tools like guetzli and mozjpeg's binary-search front-ends, and it produces materially better results than naively lowering quality until the file fits because the search is biased toward the upper end of the quality range. PNG is excluded from this mode because PNG has no quality parameter; if you ask for a target size in PNG, the result is whatever the lossless encoder produces.

Resizing is the most effective single change you can make for big size reductions, and it is built into the same form. Most images on the web are served at their full source resolution even when they are displayed at a fraction of it — a 4032×3024 phone photo embedded in a blog post that renders 800 pixels wide on a desktop browser. Reducing the source to 1600×1200 before compression typically cuts size by 75% before the encoder even kicks in, and at the typical viewing size the result is indistinguishable. The Max Width and Max Height fields cap the output at those dimensions while preserving the aspect ratio automatically, so you can drop a folder of mixed orientations and get consistently sized output without per-file fiddling. If you leave both blank, the original dimensions are preserved and only the encoder does the heavy lifting.

Bulk processing is supported by default. Drop ten or fifty images and the queue table shows each one with its original size, output size, percentage saved, and a per-row download button. The Compress All button processes the queue serially — there is no benefit to parallelism in the browser because the canvas encoder uses a shared worker pool, and serial processing keeps the UI responsive and progress visible. Total saved bytes and average percentage are shown at the top so you can see at a glance what the workflow saved you. Files where the encoder produces a result larger than the source — which sometimes happens for already-compressed PNG icons or low-quality screenshots — are left as the original and labeled "Already small" so you do not download a worse version.

A common surprise is when the compressor declines to make an image smaller. There are three legitimate reasons this can happen, and the tool handles each correctly. First, some PNGs are already optimally compressed by the source program (Photoshop's Save For Web, Figma's export, Sketch's PNG export) and re-encoding through a canvas does not improve them. Second, some screenshots have a large flat-color background that compresses beautifully with PNG's deflate algorithm but expands when re-encoded as JPEG; the tool detects this case and keeps the original. Third, very small icons (under 5 KB) often have so little entropy that re-encoding adds metadata overhead larger than any compression savings. In all three cases the row is marked as "Already small — kept original" rather than producing a worse output.

Privacy is the headline benefit and worth being precise about. The image bytes you drop into this tool are read into JavaScript memory using the standard FileReader / File API, decoded with createImageBitmap (which is a thin wrapper over the browser's image decoders), drawn to a canvas, and re-encoded with canvas.toBlob. None of those APIs make a network request. The browser's network panel will show zero requests during compression, and you can verify this with the DevTools Network tab. There is no cloud account, no telemetry on the contents of your images, no training data extraction, and no log retention because nothing leaves the page. If you are bound by GDPR, HIPAA, an NDA, or simply your own policy of not sharing customer photos with third-party services, this tool is the only category of compressor that does not require a vendor-risk review.

Performance scales with your device. On a modern laptop, a single 4 MB photograph compresses in 100–200 milliseconds; a folder of fifty photographs takes under thirty seconds. On older hardware, expect roughly 3–5x more time. The bottleneck is the JPEG / WebP / AVIF encoder which the browser implements in native code — it is fast but not infinitely so, and AVIF in particular is much slower than JPEG (roughly 5x) because of the codec's design. If you are batch-compressing thousands of files, a server-side tool like sharp on Node.js or libvips on the command line will outperform the browser; for the realistic interactive case of dropping a handful or a folder of files, the browser is fast enough.

A few practical patterns worth knowing. First, do the resize step before the quality step in your head: cutting dimensions saves more bytes than dropping quality, and quality drops produce noticeable artifacts faster than resize does. Second, for photo content, prefer JPEG quality 78–82 or WebP quality 75–80 — both produce visually-identical-to-source output in head-to-head tests but WebP is ~30% smaller. Third, for graphics with sharp edges and text, prefer PNG (lossless) or WebP at quality 90+ — JPEG mangles text edges. Fourth, transparency must use PNG, WebP, or AVIF; JPEG cannot represent transparency and will composite onto a white background. Fifth, never upload original photographs to a chat or email without compression — modern phone cameras shoot at 4032×3024 or higher, which is overkill for any non-print use case and triples your upload time.

There is one common misconception worth addressing. "PNG compression" is a confusing term because PNG is itself a lossless format that already includes deflate compression. When TinyPNG and similar tools advertise "PNG compression", they are doing one of three things under the hood: re-encoding to a different format (often WebP) with lossy quality, palette-quantizing the PNG to 256 colors with a tool like pngquant, or running an aggressive lossless re-encode with oxipng or zopfli. This tool's PNG path is the third option — a lossless re-encode through the canvas — which removes metadata and may improve compression slightly on poorly-encoded source PNGs, but does not perform palette quantization. If you have a graphic where 256 colors is enough (logos, icons, simple illustrations), the right move is to convert to WebP at quality 95–100, which gives near-PNG quality at much smaller file size, or to use a dedicated palette-quantization tool.

This compressor pairs naturally with the other Omnvert image utilities. The Crop tool reduces image area before compression, which compounds the savings. The Resize tool is more flexible than the inline Max Width / Max Height controls when you want exact pixel dimensions or fit-in / smart-crop behavior. The Filters tool covers WebP/AVIF format conversion with rotate and flip in addition to compression. The EXIF Remover strips metadata before compression for the cases when you want to share a photograph without leaking GPS coordinates. The Background Remover gives you a transparent PNG that the compressor can then re-encode to a much smaller WebP. All of these run in the browser with the same privacy guarantees, so an entire image preparation workflow can happen in a single tab without a single byte going to a server.