One operation
This site converts pictures to JPG. That is the whole of it. There is no editor here, no crop, no filter, no resize field and no second output format, and the absence of those is deliberate rather than a stage the site has not reached yet. A converter that also crops is a worse converter, because every decision it has to make about cropping is attention it is not spending on the decisions JPEG actually forces.
Those decisions are three. How much quality to spend, since JPEG is lossy and the encoder has to be given a number. What colour goes behind transparency, since JPEG has no alpha channel and something must. And what happens to the metadata, since a photograph carries a capture date and often a set of coordinates, and both dropping them silently and keeping them silently are the wrong answer. All three are controls on the page, and each one says what it costs.
How it runs
Decoding and encoding both happen on this computer. The page is a static export with no server behind it: there is no API route on phototojpg.com that accepts a picture, because there is no API route at all. A file that lands here is read into memory, decoded, re-encoded, and handed to the browser’s download machinery. When the tab closes it is gone.
The heavy parts go to a background worker wherever the browser has the pieces for one, which is why a queue of two hundred photographs does not freeze the page. Where it does not — the requirement is OffscreenCanvas, which Safari only picked up in 16.4 — exactly the same code runs on the page’s own thread, and a long queue makes the tab sluggish while it works. The HEIC decoder is a WebAssembly build of libheif, about 1.5 MB, fetched the first time a HEIC is opened and never on a visit where none appears. The TIFF reader loads on the same terms. Everything else is the browser’s own decoding, which is already there.
What it will not do, and where that work belongs
It will not aim at a file size. Somebody arrives here every day wanting a photograph under fifty kilobytes for an exam portal, and the honest answer is that this converter picks a quality number rather than a number of kilobytes. Searching for the quality that lands under a cap is a different tool with a different interface, and it lives at compresspicture.com.
It will not resize a picture on request, produce a PDF, rotate a batch of sideways photographs as a feature, or write any format other than JPEG. There is one case where the pixel count does change: a picture too large for the browser to hold stops and asks, and only if you agree does it work from a smaller copy — with the long edge it settled on printed on the row. Those are all real jobs and none of them is this one. The site normalises orientation when it reads a file because a sideways preview would be a lie about the output, and it stops there.
It also does not control chroma subsampling, which is a limitation rather than a boundary. The browser’s encoder decides, and making it a real control needs a second encoder compiled to WebAssembly. That is the next substantial thing to build here.
Who runs it
PhotoToJpg is an independent single-purpose tool, built and maintained by the team behind PictureEditor.com. The attribution line in the footer is the only place that relationship appears, and it is a line of plain text rather than a link — a credit, not a route out of the site.
Corrections and bug reports are welcome, and a file that fails to convert is the most useful thing to send: the format, the device it came from, and the message the row printed. Write to hello at phototojpg.com.