The job is fewer bytes, not a new extension
A form wants 500 KB. Your camera JPEG is 4.2 MB. That is this page: quality slider, resize slider, canvas encode, up to ten files. If the form instead wants “PNG only” and your file is already a 200 KB JPG, you wanted the format converter. I split those tools because people google both phrases and they are not the same pipeline. Here you still pick JPEG, PNG, or WebP as the output codec because canvas has to emit something, but the knobs that matter are quality percent and resize percent. Default thinking: drop quality first, downscale only if the pixel box is larger than the destination (a 4000 px photo into a 1200 px blog slot).
Keep the original. High compression smears UI text in screenshots. Tiny icons do not get smaller in a way you will notice; they get uglier. Canvas JPEG typically writes no EXIF, so GPS often disappears as a side effect. Treat that as luck, not a privacy feature. If the job is metadata, use the EXIF remover. If the job is a PDF attachment, compress pictures first, then stack.
Worked example: 4.2 MB photo into a 500 KB job portal
Leave resize at 100% first. Drop quality to ~0.7 and encode JPEG. If you are still over 500 KB, resize to 70% and try again. If the face looks like a painting, you went too far; bump quality and shrink the pixel box instead. A 4000×3000 photo at quality 0.4 looks worse than a 1600-px-wide photo at 0.8 for the same byte budget.
Worked example: a PNG screenshot of an IDE
Text, hairlines, a dark theme. JPEG at 0.5 will ringing-artifact every glyph. Stay PNG or use a high JPEG quality and only downscale if the screenshot was retina-sized for a 1× blog. If the PNG is already 80 KB, stop. Compressing “because the tool exists” is how docs look drunk.
Worked example: ten product shots, the eleventh is ignored
The script caps at ten files and says so. That is a memory ceiling with a polite number. For a catalogue, do two batches. Compare original vs compressed sizes on the card before you overwrite anything. If “savings” is 2% on an already-optimized WebP, you are done.
What will disappoint you
Already-tiny favicons. Photographs saved twice through WhatsApp. PNG photographs (huge, photographic) that you refuse to allow as JPEG: lossless PNG will not magically drop 80%. Animated GIF: canvas usually keeps a frame, not the animation. HEIC: if the browser cannot decode it, it never reaches the slider. Max dimension after resize is still a canvas; a phone tab plus ten 12 MP images will choke. This is not the PDF compressor. A PDF is a different container.
Resize is a percent of the current pixel box, not a target long-edge in pixels. 50% of 4000 px is 2000 px, which is still large for a thumbnail. If the destination is a 320 px avatar, do the math or crop in an editor. Quality 100% JPEG can be larger than the original camera file because canvas re-encodes without the camera’s own tables. If the output grew, raise nothing; keep the original or drop quality. Compare the card’s original vs compressed bytes before you replace the file in a DAM.
Questions
Is this the same as the format converter?
No. This page is quality + resize to hit a byte budget. The format converter is a codec swap (PNG/JPG/WebP) at a fixed 0.95 quality with no resize slider.
Are images uploaded?
No. Canvas encode stays in this tab. Keep originals on disk anyway.
Does compression strip GPS EXIF?
Canvas JPEG usually writes no EXIF, which is a side effect, not the feature. Use the EXIF remover when metadata is the job.
Why is screenshot text mushy?
You used a low JPEG quality on UI pixels. Stay PNG, or raise quality and downscale less.
How many files?
Ten. The script slices extras. Batch a catalogue.
Will a PNG photo shrink a lot without switching to JPEG?
Usually no. Photographic PNG is a bad container for this job. Allow JPEG or WebP if the destination accepts them.