Choose up to 50 images, set one shared recipe and download the results as a ZIP. Transparent areas stay transparent in PNG and WebP unless you choose the fill colour, and re-encoding does not carry over animation or metadata.
Runs locally in your browserAdd your images, set one recipe — output format, quality, maximum width and what happens to transparent areas — and press Process files. Every file is decoded, drawn on a canvas at the output size and encoded again in the chosen format; the results are packed into a ZIP named kivtools-converted-images.zip. All of it runs in the tab: the images are never uploaded.
A batch shares one recipe. There is no per-file format or width, and a single image still arrives as a ZIP. The metrics above the output panel report the number of files, the total input size and the total output size.
Quality is handed to the browser encoder as a value between 10 and 100 and it applies to WebP and JPEG. PNG is lossless, so the control cannot change its bytes: the same 1600x1200 photo exported as PNG at quality 10 and at quality 100 produced files of exactly 840,050 bytes each. For PNG, the maximum width is the only control that reduces the weight.
The field is corrected instead of being passed on silently, because a quality of 0 encodes a file that looks broken and an empty field used to do exactly that. Out-of-range widths are corrected the same way: a negative maximum width becomes 0, which keeps the original size.
The limit is applied to the width only; the height follows the ratio and is rounded to whole pixels. A 4000x100 pixel banner becomes 1920x48 at the default maximum width of 1920 and 600x15 at 600, and a 1600x1200 photo becomes 600x450 at the same setting. Images narrower than the limit are left alone: a 300x900 portrait stays 300x900, because the tool never enlarges an image.
SVG has no pixels of its own until it is drawn. A file that declares no width or height is rasterised at the browser default of 300x150; one that declares 320x160 keeps those dimensions.
PNG and WebP output can keep transparency, which is the preselected behaviour: a test image that is half transparent came back with an alpha channel that still contained fully transparent pixels. Choosing the fill option replaces those pixels with the colour in the field next to it; with #ff00aa selected, the transparent half of the same image was written as that exact colour.
JPEG has no alpha channel, so its output is always filled, even while the keep option is selected: the colour field decides what those pixels become. That is a property of the format, not an option that was left switched on.
The output is a fresh canvas encode of the pixels, so the original metadata is not copied: a JPEG carrying an EXIF block came back as a WebP whose chunks were only VP8X, ICCP and VP8. An animated GIF is decoded as its first frame, so a single still image is written per input file.
Inside the ZIP, spaces and characters that are not allowed in file names are replaced with a hyphen — “две картинки.png” is stored as “две-картинки.webp” — and the extension follows the chosen output format. Two files that would land on the same name are numbered instead of overwriting each other: two shots named shot.png arrive as shot.webp and shot-2.webp, and the status line reports how many files were renamed.