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 it to about 6.7 MB of files. Compression takes it further: the engine gzips to roughly 1.5 MB, and the language data has to be shipped pre-compressed at 1.9 MB because it carries no MIME type a server will recognise and squeeze on its own. That is3.4 MB actually crossing the wire, from 13.8 MB of published files. 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 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.

It will not do two things at all, and both matter 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. I tried both on that receipt and 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. Measure preprocessing on your own image rather than trusting the advice.

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.

How to change text in an image without Photoshop

Worth understanding what you are actually skipping, because Photoshop is not one answer to this problem. It is three, and two of them hit the same walls described above.

Content-Aware Fill is the classic route: select the old words, let it synthesise a patch from surrounding pixels, then set new type on top. It is patch-based rather than generative, so it behaves much like the flat-background repair any browser can do. On a screenshot it is excellent. On brick it smears, for exactly the reason a browser tool smears on brick.

Generative Fill is the newer route and it is the one that genuinely does something a browser cannot. It also runs on Adobe’s servers rather than your machine, needs an account and a connection, and draws down generative credits. If your reason for avoiding Photoshop was that you did not want the image leaving your computer, that route does not solve it either.

The part people expect Photoshop to solve and it does not is the typeface. Match Font can identify type in an image only against fonts you already have installed or can pull from Adobe Fonts, and it wants reasonably large, flat, horizontal lettering to work from. It is the same wall measured earlier in this article: the width signal simply is not distinctive enough, and a subscription does not change the arithmetic.

So the practical answer is that on a flat background you need none of it. Removing text from solid colour and setting replacement type is measurement and drawing, both of which a browser does natively. Photoshop earns its subscription on the textured case, and on that case it is worth the money.

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. Of the six I looked at, one 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

You will read 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 3.4 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. I set the same word in both and measured the ink box: 4.28 in Helvetica, 4.29 in Georgia. A serif and a sans, and the number that was supposed to tell them apart agrees to two decimal places. 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.