How to Edit Text in an Image

If the text is part of the picture, you cannot simply click it and retype. The letters are pixels, no different from the sky behind them. Nothing in the file records which pixels were once a word, what typeface it was, or what was underneath it.

Tools that appear to edit text in an image are not editing anything. They are reading the text with one model, erasing it and inventing replacement background with a second, then drawing new letters that imitate the original. It works, sometimes very well, and it is expensive enough that most products charge for it.

What it actually takes

Replacing a word inside a photo needs four separate capabilities:

• Optical character recognition to locate the text and work out where each character begins and ends.
• Font identification to guess the typeface, weight and slant from a handful of rendered letters.
• Inpainting to remove the old text and invent the background that was hidden behind it.
• Style matching so the new lettering inherits the same colour, lighting, grain and perspective as the old.

Two of those four you can run yourself, one is cheap arithmetic once the first has finished, and one cannot be bought at any price a browser can afford. Recognition is a solved problem, though heavier than people expect. Style matching is measurement: colour, size, weight and position all sit in the pixels waiting to be read. Font identification does not work at this scale, for reasons worth seeing the numbers on. And inpainting is the one that decides whether the whole thing succeeds.

The measured cost of the easy part

Tesseract is the standard open-source OCR engine, and tesseract.js is its browser build. Downloading what a browser needs before it can read a single word:

That is 13.8 MB, against roughly 16 KB for a tool page. Around 850 times the weight, fetched before anything happens, for one step of the four.

It can be cut, and by more than you would guess. Tesseract publishes its language data in two builds, and the smaller one is 3.9 MB against 14.6 MB for the accurate one. The engine core also ships in a variant carrying only the modern recognition path, at 2.7 MB rather than 3.3 MB. Choosing both trims the download to about 6.7 MB. That is still far too much to load with a page, which is the real lesson: the cost is survivable only if nothing pays it until someone actually asks for a scan.

And OCR on photographs is the shaky part of Tesseract. It was built for scanned documents: level baselines, plain fonts, clean contrast. Point it at a logo, a curved sign or condensed lettering over a busy background and accuracy drops sharply.

Two things it will not do at all are worth knowing before you plan around it. It does not read handwriting. Run a photographed tailor’s receipt through it and the printed labels come back while every handwritten entry is missed, because the training data is printed pages. And the language model is per-script, so a receipt carrying Urdu or Chinese needs a different model file, on top of the megabytes already counted.

The standard advice for improving it is to enlarge the image towards print resolution and desaturate it, since blue ballpoint is a strong colour difference and a weak brightness one. Tested on that receipt, both made things worse. The original produced fifteen usable lines, enlarging dropped it to thirteen, and enlarging with a contrast stretch to twelve. Tesseract already does its own scaling and thresholding, and a stretched copy mostly amplified the sensor noise. Preprocessing is worth measuring rather than assuming.

Inpainting is the part that actually decides quality

Erasing text is easy. Deciding what should be in its place is not.

On a flat background it is nearly free: sample the surrounding colour and fill. That is why these tools look flawless in demos, which almost always use a solid-colour banner or a plain product label.

On a photograph it becomes generative work. Text sitting across a brick wall, a face or foliage means reconstructing brick, skin or leaves that were never captured. Classical algorithms smear; the results people share as impressive come from diffusion models measured in hundreds of megabytes and run on someone else’s hardware.

This is the single best predictor of whether an AI text editor will work on your image. Flat background: likely fine. Textured background: expect to notice the repair.

So what should you do instead?

Go back to the source file

Always the right answer when it is available. The original Figma file, Canva design, PSD or slide still has the text as text. Editing takes seconds and loses nothing. It is worth checking before assuming the flattened image is all that exists.

Cover and re-draw it

If the background behind the text is a solid colour or a simple gradient, remove the old text by extending the pixels beside it inwards and draw the new words on top. Crude in description, and on flat backgrounds indistinguishable from a proper repair. This is what most people actually need when they want to edit text in an image, and it is the case that covers screenshots, receipts, forms, invoices and app captures.

The Image Text Editor here does this without uploading your picture. It scans the image, rebuilds the words into lines, measures each one, removes it and lets you type over it. On a generated receipt it recovered the colour of every line exactly and the size to within about a pixel. What it will not do is the generative half, so it refuses logos and watermarks outright and warns you when a line sits on texture.

Add new text rather than replacing old

Captions, watermarks, titles, memes and social cards do not need the old text touched at all. That is a layer on top, which any browser can do without a model.

Pay for the AI tools when the job warrants it

When the background is genuinely complex and the source file is gone, the paid services are the realistic option. Expect to upload the image and pay per result. One of the tools reviewed for this article sells credits starting at $1.99, and another keeps uploads for between three and thirty days depending on account status. Worth knowing before you send a screenshot containing anything private.

Where the line actually falls

The common claim is that none of this can be done in a browser. That is half right, and the half that is wrong is worth being precise about, because it decides whether you need to pay.

Recognition runs locally at a cost of about 6.7 MB, paid once and cached. Style matching runs locally for nothing, because it is measurement rather than inference. Removing text from a flat background runs locally for nothing too. Three of the four capabilities are within reach of a tab, and together they cover the images most people are actually holding: a receipt, a form, a screenshot, an invoice.

Two things stay out of reach. Font identification needs a classifier trained across thousands of typefaces, and the signals available without one are not close to sufficient: measured on the same word, the ink box sets to 4.28 in Helvetica and 4.29 in Georgia. Inpainting worth the name is a diffusion model in the hundreds of megabytes, and no amount of cleverness substitutes for it when the words sit over brick or a face.

So the paid products are not selling you the easy three quarters. They are selling the generative quarter, which genuinely does cost money per image, and that is why they carry a credit balance or an account. Judge a free browser tool by whether it says which part it is doing. One that quietly draws a layer on top and calls it editing is the thing to avoid.