Methodology
How the numbers on this site are measured.
Most converter sites tell you a conversion will make your file “up to 90% smaller.” That number is almost always invented, or copied from a site that invented it. There is no source file behind it, no settings, and no way to check.
Every figure on Filesmith comes from running the conversion on a real file and reading the result. That is why the PNG to JPG page says 2,327 KB down to 452 KB rather than quoting a range, and why it names the photo’s dimensions and describes what kind of image it was. Convert something different and you will get a different number — but you can at least see what produced this one.
This page covers what was tested, where, and what the results do and don’t tell you.
6Source files
33Converters measured
4We advise against
The test files
The same small set of source files runs through every relevant converter. Using one corpus means figures on different pages sit on the same scale — the 2,443 KB on the JPG to WebP page and the 2,443 KB on the JPG to AVIF page are the same photograph.
Every photo and screenshot was taken on a Google Pixel 7. Each was chosen to be difficult in a specific way.
-
Photo A — gradients
12.5 megapixels, 3072 × 4080, with a large area of smooth sky. Gradients are where lossy compression shows banding first, and where lossless formats have the least redundancy to exploit.
2,443 KB JPG · 325 KB AVIF · 691 KB WebP q80 · 10,247 KB PNG · 36,720 KB BMP
-
Photo B — noise
1080 × 2400, large dark areas with visible sensor noise. The opposite problem: noise is close to incompressible losslessly, which makes this a best case for converting away from PNG and a worst case for converting to it.
2,327 KB PNG · 452 KB JPG q90 · 176 KB WebP q80 · 89 KB AVIF q50
-
Photo C — already compressed
1280 × 964, already reduced to 85 KB as WebP. A source that has lost information before the test begins. Converting it again can only add size, never restore quality, and this file is what demonstrates that.
85 KB WebP · 189 KB JPG · 1,009 KB PNG
-
Screenshot — hard edges
A 243 KB screen capture: sharp edges, text, and large flat areas of a single colour. Exactly the content photographic compression handles worst.
243 KB PNG · 65 KB lossless WebP
-
Video
A 13.8-second clip at 2160 × 1064, roughly 20 MB. Long enough to measure meaningfully, short enough to run repeatedly across every video converter.
~20 MB source · 315 KB extracted MP3
-
Audio
One recording, held in every format the site handles. Because it is a single source in six containers, every figure on the audio pages is measuring the same performance.
2,576 KB WAV · 934 KB FLAC · 539 KB MP3 320 · 324 KB MP3 192 · 325 KB M4A · 241 KB OGG
The test environment
All figures were measured in Chrome on a Google Pixel 7, using the same builds this site serves to you. The numbers come from the tool you are actually using, not from a desktop application that happens to share a name with it.
For images, the browser is the encoder. Filesmith hands the image to the browser’s own Canvas encoder with a quality setting and takes back what it produces. There is no bundled JPEG or WebP or AVIF library. That means these numbers describe Chrome specifically — Firefox and Safari ship different encoders, and the same photo at the same quality setting will not come out at exactly the same size in all three.
Everything that isn’t an image goes through a pinned library, so those results are consistent across browsers:
- Audio & videoFFmpeg.wasm —
@ffmpeg/core-mt 0.12.10 with @ffmpeg/ffmpeg 0.12.15. A few older pages still run the 0.11 line.
- TIFF
utif2 4.1.0
- HEIC decoding
heic2any 0.0.4
- PDF
pdf-lib 1.17.1 for writing, pdf.js 3.11.174 for reading
- GIF
gif.js 0.2.0
Hardware isn’t listed because it doesn’t change the answer. A given encoder at a given quality produces the same bytes on any machine; only the time it takes varies. Where a page talks about speed rather than size, treat it as a phone-class result and expect a desktop to be faster.
Every size is the actual file on disk after conversion, in kilobytes, as the operating system reports it — not an estimate, and not calculated from a bitrate.
What these comparisons are, and what they are not
This is the part most sites are vague about, so to be direct: these are not controlled codec benchmarks.
Each figure is one real file put through one real conversion at the settings the tool actually used. When a page shows a photo as JPG, WebP and AVIF side by side, those are three outputs at three stated quality values — not three encodings held to identical measured image quality. Doing that properly means encoding at many quality steps and comparing each result against the original until they match, and that isn’t what produced these numbers.
The distinction matters when you read them. These figures answer “what will this conversion do to my file?” — which is the question you actually have when you land here. They do not answer “which codec is objectively more efficient?”, and any page that claims to answer the second question with a single before-and-after pair is overreaching.
Quality values are stated everywhere for the same reason. “452 KB as JPG” on its own means nothing; the pages say quality 90, because at quality 35 the same photo would be a quarter of the size and visibly damaged.
When the measurement says don’t bother
Four converters on this site tell you not to use them. That is deliberate, and it is simply what running the tests produces if you publish what you find rather than what sells.
WebP to PNG turned an 85 KB file into a 1,009 KB one — 11.8 times larger for no gain in quality, because the source had already discarded the detail PNG would have preserved. That page says so at the top rather than burying it.
MP3 to WAV took 324 KB to 2,576 KB, roughly 8× larger, and recovered nothing — the information was gone before the conversion started. AVIF to JPG took 325 KB to 1,321 KB. JPG to PNG took 2,443 KB to 10,247 KB, more than four times the size, to store losslessly a photograph that had already been compressed lossily.
All four remain available, because sometimes compatibility is worth the size and only you know whether it is. But the page tells you the price first.
What these numbers don’t tell you
They are single measurements on single files, not averages across thousands. A photo unlike the test photos will behave differently — which is why each page describes its source rather than quoting a bare percentage.
Image results are Chrome results. Because the browser does the encoding, someone converting the same photo in Firefox may get a slightly different file size from the one published here.
Library versions change. A result measured today can shift when FFmpeg or any of the others updates; where that happens the page is re-measured rather than left to drift.
And file size is only one axis. A smaller file that nothing on your device can open is not the better outcome, which is why several pages recommend the larger format.
Check it yourself
Everything here runs in your browser using the same code this page describes. Take one of your own files, convert it, and compare the result against what the page predicted. If a figure on this site is wrong, it is checkable — which is the entire point of publishing the method.
Found something that doesn’t hold up? hello@filesmith.io. Corrections get published.