Benchmark: in-browser vs upload-based image tools
We timed OptImg against iLoveIMG on identical files, the same machine and the same connection. Here is the method, the numbers, and the cases where the gap is smallest.
Measured:
Every image site claims to be fast. Almost none of them say what they measured, on what file, over what connection, or where their approach loses. This page is our attempt to do the opposite.
We compared OptImg, which processes images inside your browser, with iLoveIMG, a widely used service that uploads your file, processes it on a server, and sends the result back. Both were driven by the same script, in the same browser, on the same machine and connection, using the same input files, in a single sitting.
What we measured
The number we report is task time: the stopwatch starts the moment the file is handed to the page and stops when the last byte of the finished file has been written to disk. That covers everything a person actually waits through — for an upload-based service the upload, the queue, the processing and the download; for OptImg the code download, the decode, the processing and the local save.
Starting the clock at the file handover rather than at the button click matters for fairness. Upload-based services begin sending the file the moment you choose it, so a stopwatch that starts at the button would quietly delete their upload time from the comparison.
Each cell is the median of three runs, and every run uses a fresh browser with an empty cache. That deliberately puts OptImg at its worst: it re-downloads its processing code inside every measured run, exactly as a first-time visitor would.
Test environment
| Hardware | Apple M3 Pro, 18 GB RAM |
|---|---|
| Operating system | macOS 26.5.2 |
| Browser | Chromium 149.0.7827.55 |
| Connection | ≈95 Mbps down / ≈129 Mbps up, 16 ms idle latency (home fibre, Seoul) |
| Throttled profile | 9 Mbps down / 1.5 Mbps up / 60 ms round trip |
Results
Task time in seconds, lower is better. The difference column shows how many times longer the upload-based round trip took.
On a home fibre connection
| Task | Input file | OptImg | iLoveIMG | Difference |
|---|---|---|---|---|
| Compress a 5 MB photo | 4.9 MB · 4000×3000 | 0.95 s | 14.54 s | 15.3× |
| Convert a 20-megapixel PNG to WebP1 | 47.8 MB · 5477×3651 | 2.58 s | 29.12 s | 11.3× |
| Convert a 20-megapixel photo to AVIF2 | 2.8 MB · 5477×3651 | 6.02 s | not offered | — |
| Resize a 20-megapixel photo to 50% | 2.8 MB · 5477×3651 | 0.96 s | 12.74 s | 13.3× |
| Extract 50 GIF frames as images | 5.3 kB · 50 frames | 1.47 s | 8.80 s | 6.0× |
On a throttled 4G connection
| Task | Input file | OptImg | iLoveIMG | Difference |
|---|---|---|---|---|
| Compress a 5 MB photo | 4.9 MB · 4000×3000 | 0.93 s | 38.55 s | 41.5× |
| Convert a 20-megapixel PNG to WebP1 | 47.8 MB · 5477×3651 | 2.61 s | 282.35 s | 108.2× |
| Convert a 20-megapixel photo to AVIF2 | 2.8 MB · 5477×3651 | 6.58 s | not offered | — |
| Resize a 20-megapixel photo to 50% | 2.8 MB · 5477×3651 | 1.01 s | 25.95 s | 25.7× |
| Extract 50 GIF frames as images | 5.3 kB · 50 frames | 1.50 s | 9.49 s | 6.3× |
- The WebP row is not a like-for-like comparison. iLoveIMG offers no WebP output at all, so its cell is the closest thing it has: the same PNG through its PNG-to-JPG converter. Never quote that row without this caveat.
- iLoveIMG has no AVIF output anywhere, so that row is reported as unsupported rather than as a win.
How to read these numbers honestly
- The gap is mostly network, not cleverness. OptImg wins because it never sends your file anywhere; on a fast connection with a small file, that advantage shrinks, and the smallest margin in this suite is exactly that case.
- OptImg's times depend on your computer, because the work happens there. These figures come from the machine listed above. An older phone will be slower on the same file; a faster desktop will be quicker.
- iLoveIMG's times depend on their server load and how far you are from it. Three runs on one day from one city is a snapshot, not a service guarantee.
- The outputs are not identical. Both services were run at their own defaults, so file sizes and quality settings differ between them. This is a measurement of time, and the output sizes are in the raw data so you can see exactly what each produced.
Reproducing this
The test images are generated from a fixed formula rather than picked by hand, so anyone can recreate byte-identical inputs instead of trusting ours. The full method, the fairness rules, and the known limitations are documented alongside the code.
The raw measurement files below contain every individual run: the timing marks, the resulting file sizes, and the environment the run happened in.