Batch image conversion that never uploads a file

Built for a queue, not for one file at a time

Most browser converters handle one image and then ask you to do it again. This one is a work queue: add fifty files, reorder them, change the output format for a single row, cancel one that is taking too long, retry the ones that failed, and download everything as a ZIP with a manifest recording exactly what happened to each file.

How many run at once is decided by your device rather than by a fixed number. Each conversion holds the source, a decoded copy and the encoder's working memory at the same time, so running eight at once on a laptop is how a browser tab gets killed halfway through a batch. Safari gets a single worker because it is the least forgiving under memory pressure — slower, but it finishes.

One bad file does not end the batch. A truncated PNG, a TIFF using a compression the decoder does not have, or an image so large it exhausts the memory a tab is allowed will fail on its own row with an explanation, and everything else carries on.

Honest about what conversion can and cannot do

Converting a JPEG to PNG does not restore what the JPEG threw away. It stores the artefacts losslessly, and the file usually gets larger. Converting a transparent PNG to JPEG does not keep the transparency, because JPEG has no way to store it — the transparent areas are filled with a colour, and you choose which one rather than being given white and no explanation.

Where something is lost, the page says so before you convert and the result says so afterwards. Where a browser cannot do something at all, the tool refuses rather than producing a file that opens but is wrong.

Camera raw is decoded, not previewed

A raw file is not a picture. It is one brightness reading per photosite behind a coloured filter, and turning it into an image means interpolating the two colours each pixel did not measure, applying the white balance the camera recorded, and mapping the sensor's response through a colour matrix measured for that exact camera model.

All of that happens here, using a mature decoding library also used by desktop photo software, fetched only when you add a raw file. The normal path decodes sensor data rather than pulling out the JPEG preview stored inside many raw files. Where sensor data genuinely cannot be decoded, that preview is offered as a clearly labelled fallback and never as the real thing.

Camera, lens, exposure and true sensor dimensions are shown when the decoder can read them. Supported metadata fields travel into formats that can store them; the file details show whether GPS data exists, but coordinates are deliberately not written.

Every file is checked before you get it

A converter can hand you a file that is the wrong format, upside down, missing its transparency or simply not decodable, and every one of those looks like success until you open it somewhere else. So each output is put back through the same identification and decoding path an input would take: its signature is read from its bytes, its dimensions are compared against what was asked for, it is decoded again, and those pixels are compared with the ones that went into the encoder.

Anything that fails those checks is reported as a failure instead of being offered as a download.