Image translator

Two steps, and only one of them is negotiable

Translating an image is really two jobs.

Reading the text is the sensitive half. It requires the picture, and the picture is the thing you might not want to hand over: a contract, a prescription, a letter, a whiteboard after a meeting. This step is done entirely on your device, always, with no exception and no setting that changes it.

Translating the text requires a language model. There is no honest way to deliver one to a web page, so this tool does the next best thing and uses your browser’s own, when your browser has one. Chrome and Edge from version 138 include an on-device translator, and where that is present nothing leaves your machine on either step.

Where it is not present, you get the extracted text and an explicit button. The button is labelled with where it sends the text, nothing happens until you press it, and the image is not part of it either way.

Why structure survives here

Most image translators flatten the page. The text comes out as one long string, goes to a translation service as one long string, and comes back with every heading, bullet and table cell run together.

This one reconstructs the layout first, using the position and size of every line the recognition step found, and then translates each piece separately. A heading stays one unit. Each list item stays one unit. Each table cell is translated on its own, so a table with three columns comes back with three columns.

That is also better translation, not just better formatting. Sentence boundaries are what a translation model uses for context, and a table read as prose gives it boundaries that were never there.

Read the left side before trusting the right

This is the one habit worth building with any image translation.

Recognition errors do not announce themselves after translation. A misread digit in a price, a name read as a similar word, a negation lost to a smudge: all of them arrive on the other side as fluent, confident, wrong output. The translated text has no way to signal that its input was already damaged.

So the original is shown next to the translation rather than being hidden. Scan it first. If something in the extracted text looks wrong, the translation of it is wrong too, and the fix is a better photograph rather than a different target language.

What it is good at, and what it is not

Good: menus, signs, packaging, forms, screenshots of software in another language, printed letters, and anything where the type is clean and the layout is simple.

Poor: handwriting, which the recognition step barely reads in any language. Stylised display type on posters. Text over busy photographic backgrounds. Vertical text. Anything where the recognition confidence comes back low, which is reported on the page for exactly this reason.

Not attempted: putting the translated text back onto the image in place of the original. That is a genuinely hard problem involving inpainting and font matching, and doing it badly produces something that looks authoritative and is unreadable. The text is given to you as text, which is also what you can then paste somewhere.

Where the languages come from

The recognition side reads 102 languages. The translation side offers whatever pairs your browser supports, which is a different list, and the tool checks the specific pair you have chosen rather than assuming. Some pairs that avoid English entirely are unavailable even in browsers that translate well, and you are told that plainly instead of being given a spinner that never resolves.