Skip to content

How oCompress works

What happens when you drop a file, how you can check that nothing is uploaded, and what lossless and lossy compression really mean.

The short version

When you open a tool page, your browser downloads the page and a small program, the compressor. When you add a file, the browser reads it, the compressor processes it on your own processor, and the result is handed back to you as a download. At no point is the file sent over the network. The whole process looks like this:

  1. Load. The page and the tool interface load first. The engine for a file type (images, video and audio, or documents) is fetched only when you add a matching file, so you never download code you do not use.
  2. Read. Your browser gives the page access to exactly the files you chose, nothing else on your device.
  3. Compress. The work runs in a Web Worker, a background thread of the browser, so the page stays responsive and you can cancel at any time.
  4. Save. The compressed file is created in memory (large videos in the browser's private storage) and saved through your browser's normal download, one by one or as a ZIP.

What runs in your browser

Modern browsers can run compiled code at close to native speed through WebAssembly, and they give web pages access to the hardware video encoders of the device through an interface called WebCodecs. oCompress uses both:

  • Images: MozJPEG for JPEG, OxiPNG and a palette quantizer for PNG, the WebP encoder from Google's libwebp, libavif for AVIF, SVGO for SVG, and dedicated decoders and encoders for GIF and TIFF. The JPEG, PNG, WebP and AVIF codecs are compiled to WebAssembly.
  • Video and audio: WebCodecs with the Mediabunny library to read and write containers such as MP4 and WebM. Encoding uses the hardware encoder of your graphics chip where available, which is why it can be fast even in a browser. MP3 files are written by the LAME encoder and FLAC files by libFLAC, both compiled to WebAssembly and loaded only when needed.
  • Documents: our own code built on open-source PDF and ZIP libraries opens PDFs and Office files, recompresses the pictures inside with the image codecs, and writes a new file.

Every library we ship is open source: most under permissive licenses such as MIT, BSD and Apache 2.0, Mediabunny under the MPL 2.0, and the LAME MP3 encoder under the LGPL as a separate, replaceable file. See the list of libraries with versions and licenses.

How you can check that nothing is uploaded

You do not have to take our word for it. Two simple tests:

  • Go offline. Open a tool page, compress one file so the engine is loaded, then turn off Wi-Fi or mobile data and compress another file of the same type. It works, because nothing needs the network.
  • Watch the network. In Chrome, Edge or Firefox, press F12, open the Network tab and compress a file. You will see the compressor code being loaded from our site, and requests from analytics and ads, but no request carrying your file. A 10 MB photo would show up as a 10 MB upload; there is none.

The page does send anonymous usage events to Google Analytics, such as "a JPG of a few megabytes was compressed". These events contain the tool, the file type, and the size, saving and processing time as rough ranges, never the file name or its content.

Lossless compression: same content, fewer bytes

Lossless compression finds redundancy, things that are stored more than once or that can be predicted, and writes them more compactly. Decoding reverses the process exactly. Three ideas appear in almost every lossless format:

  • Prediction. Neighboring pixels in an image or consecutive samples in audio are usually similar. Storing the small difference from a prediction instead of the full value leaves numbers that are mostly close to zero. PNG filters and FLAC's linear predictor work this way.
  • Repetition. Repeated sequences are replaced by a short reference to the earlier copy. This is the LZ77 part of DEFLATE, used in ZIP, PNG and Office files.
  • Entropy coding. Frequent values get short codes and rare values long ones (Huffman or arithmetic coding).

Lossless compression has a natural limit: random noise cannot be predicted, so a grainy photo or a noisy recording never shrinks much without loss. This is also why compressing a file that is already compressed, such as a JPEG inside a ZIP, saves almost nothing.

Lossy compression: removing what you will not miss

Lossy codecs go further by discarding information that human eyes and ears barely perceive. JPEG and WebP store color at lower resolution than brightness and round away fine high-frequency detail. MP3, AAC and Opus drop sounds masked by louder ones. Video codecs such as H.264 store one full picture now and then and, in between, mostly motion and changes.

The quality or bitrate setting decides how much is discarded. At moderate settings the loss is very hard to notice; push too far and typical artifacts appear: blocks and halos in images, a metallic or underwater sound in audio, smearing in fast video scenes.

What the tools promise and what they do not

  • You never get a bigger file. If the result is not smaller, the tool returns the original and tells you it is already optimal.
  • Documents and audio files give identical bytes for the same file and settings; hardware video encoders may differ by a few bytes between runs.
  • Text in documents stays text; pages are never turned into pictures.
  • Image metadata such as GPS location is removed by default, while the color profile and rotation are kept. Video metadata such as location, device and dates is removed by default too; audio keeps its tags and cover art unless you turn that off.

What we cannot promise is a particular percentage. The saving depends entirely on how the file was made: a phone photo or a scanned PDF usually has plenty of room, a file that has already been optimized has little. The tool shows the exact before and after sizes for every file.

Limits of compressing in a browser

A browser tab is a sandbox with limited memory, and that sets the boundaries of what is practical. The tool accepts images up to 200 MB and 100 megapixels, PDF and Office files up to 300 MB, and video and audio up to 4 GB on a computer (1 GB on phones), though long 4K videos may still not fit in a tab's memory. Speed depends on your hardware: in our tests on a fast Windows PC in Chrome, a minute of 1080p video took about 20 seconds and a 24-megapixel photo about 2.5 seconds; phones can be much slower. Video and most audio conversions need WebCodecs, which current Chrome, Edge, Opera, Firefox 130+ and Safari 26+ provide; WAV and AIFF can become MP3, FLAC or WAV even without it.

A few formats have no decoder in browsers at all, such as WMA, AVI and WMV, and old binary Office files cannot be rewritten safely. For these, the tool explains the options rather than producing a file that might be damaged. When a job is too big for a browser, a desktop program such as HandBrake for video or LibreOffice for documents is the honest recommendation.