Head to Head on a Flattened Picture: Scene Tools, Letter-Matching Editors, and Erasers

I put the editors people actually open onto the same kind of job: a picture that already has words on it, and no layered design file behind it. The comparison is not a catalog tour. It is a head-to-head among five different bargains, because they do not fail in the same place and they should not be scored as if they did.

The subscription desktop editor is a scene tool. You drag a selection and ask it to invent what belongs in the hole. It is strong when the picture itself is the job: a background that has to continue, an object that has to go, lighting that has to stay coherent. It does not keep a font match. Letters it draws tend to look generic, and it is the wrong instrument when the wording has to be exact.

The browser design app is the same scene job with a friendlier door. You paint the area and type a prompt. Ordinary use is basically free, nothing has to be installed, and you still mark the region yourself. It does not read the line for you. Precision is limited, and the feature is still in beta. Flat social graphics are its comfort zone. A photograph with a gradient behind the words is not.

The chat editor takes the file and a sentence. You can nudge the result, try a slogan, or shift a color without learning a selection tool. The letters are the unreliable part. They come back blurry, misaligned, or misspelled often enough that I would not let them carry a price, a date, or a name.

Dedicated lettering editors are built for the opposite bargain. They find the words that are already there, clear them, rebuild what was underneath, and set a new phrase in a face, a color, and a size that try to belong to the original. They lead on font fidelity and on speed. Speed here means a short path, not a stopwatch number I am pretending to have measured. When the export is all you have, and the change is the wording rather than the scene, that is the camp I open first. For a finished picture I would rather edit text in image on a finished picture than rebuild the layout from scratch.

Removal-only tools are not a weaker copy of the editors above. They are a third camp. They delete words well, including on grounds that are busier than a flat color, and they cannot put a new word back. A beautiful erase is not evidence that the same product can reletter a sign.

No single tool does everything well. The feature people came for — type a new line and have it look native — is still the weakest link. Clean removal was easy. Convincing replacement was not. Read the table before the rest of this piece. The later sections explain the rows. They do not introduce a second set of product names.

The table, before the story

Eleven products, one job family, six columns. What it actually edits. Where it is strong. Where it stops. What the price shape is, with no invented unit price. Where the file goes. Who the row is for. A general-camp fit means the picture is the point and the letters are the gamble. A dedicated-camp fit means the letters are the point. A removal-camp fit means the words should vanish and nothing should be written in their place. Two rows are not lettering tools at all, and one row is an unreleased demo for garbled glyphs in generated pictures. Sorting them that way is the comparison.

Tool	What it edits	Strengths	Limits	Price	Privacy	Best fit
Photoshop	Delete or replace a selected element, including lettering, and generate picture content in the hole. The fill step is Generative Fill.	Strong scene context, fine control of the selection and the parameters, and it works with layer effects. The generative model family here is Firefly.	No dedicated text recognition and no font match. Generated lettering is often generic and not guaranteed to be legible. The learning curve is steep, and the work is manual.	Subscription.	Edits upload to the Adobe cloud. Login is required. Copyright rules apply.	General camp. Professional scene work: complex scenes, object replacement, background extension. Not the tool for precise lettering replacement. That still needs a manual font match on a real type layer.
Canva Express	Brush-select plus a text prompt to replace a selected element, including deleting or replacing lettering. Magic Erase removes objects or lettering. Magic Edit is that prompt brush.	Simple, in the browser, with no install. It integrates with templates. Replacing an element is fast on ordinary pictures.	Still in beta, with limited precision. Weak on complex backgrounds and on fine detail. No automatic reading of the line, so you mark the region yourself.	Basically free. Advanced features need a paid Pro plan. A chat plugin can call it without a separate charge.	Online processing, and an account is required. The privacy policy stresses that assets are kept safe, but the work is still processed in the cloud. Output is subject to copyright and community rules.	General camp. Creators doing quick element edits, or deleting and replacing lettering on flat design and social graphics, where pixel-perfect fidelity is not required.
ChatGPT + image editing	Upload a picture and describe the edit in ordinary language, including adding or removing lettering. In plugin mode it can call a desktop editor or a design app, for example to blur a background or to replace lettering through those plugins.	Flexible editing, iterative changes to part of a picture, and multi-turn consistency. The Images 2.5 model focuses on precise editing. Templates such as Sketch, and prompt sharing, are part of the flow.	Limited recognition and rendering. Expect errors or garbled spelling when the model draws the letters. No exact font match.	Free, and also Plus, Pro, and Enterprise tiers. Image editing is a general capability. Desktop plugins are reachable through the chat.	OpenAI frames the product as privacy-respecting, but uploads may be used for training, and an opt-out exists. Plugins require login and follow their own rules.	General camp. Creative prototyping and fast iteration: describing an edit in a sentence, trying a slogan, changing a color. Not for fine typographic proofing.
Pixelmator Pro	General editing and repair, including machine-learning content fill and object removal, plus enhancement and artboard tools.	A friendly interface, on-device machine learning that feels smooth, and multi-layer plus vector tools for creative work.	No dedicated text recognition or replacement. It runs on Mac and iPad only.	A one-time purchase, or a subscription through the Mac App Store. Cheaper than a full professional desktop subscription.	Mostly on-device. Data is edited on the machine. Whether anything is uploaded depends on what the person does. The editor itself adds no extra privacy exposure.	Routine editing for Mac designers: object removal and color adjustment. Not a lettering editor.
Remove.bg	Automatic background removal only. It does not edit lettering.	Narrow and efficient. Fast, accurate segmentation from a deep-learning model.	Single-purpose, and unrelated to lettering edits.	A basic free tier. Paid use covers batch and high-resolution removal.	Web or API use requires an upload. The policy says the content is not stored, or is kept only briefly in order to process.	Background removal for commerce and cut-outs. Useful as a step before manual lettering work. Not a lettering editor.
Runway ML	Cloud generation and editing for stills and for video: object removal, expansion, and video inpainting.	A creation platform for motion and for stills, with collaboration and an API. It keeps shipping frontier models, including Gen-4.5 and GWM.	Aimed at creative generation and video, not at a dedicated lettering object. Some advanced features need paid credits.	A free basic tier, pay-as-you-go, and team or enterprise plans.	A cloud service that caches processed content. Check the terms on using assets for product improvement and on commercial licensing.	Creative video and interactive work. It can delete lettering as a side effect. It cannot match a font.
ClipDrop	Cleanup removes a selected object, person, or lettering. Text Remover deletes lettering and repairs the background. The product describes that repair as analyzing the surrounding area to rebuild what was behind the text.	Simple, and the results are generally natural, including on complex backgrounds. There is a free allowance.	It can only delete. It cannot replace or add lettering, cannot keep the original style, and cannot re-typeset. It needs a network.	A free daily quota. Premium is a subscription.	An account is required for the web app. Pictures are uploaded to the cloud under Stability AI policies.	Removal camp. Clearing unwanted lettering, watermarks, or blemishes. Replacement is a different tool's job.
Fotor	Automatic recognition of text regions. Click a detected region and type the new content. The backend removes the old lettering and imitates the same letterforms with the new content. Prompt-based editing is also available.	Purpose-built for lettering in pictures. It auto-matches font, color, and effects. The flow is close to a word processor. It can delete, replace, and add lettering.	It needs a network, and processing time depends on the server. Weak on tiny type, on handwriting, and on warped type.	A free tier can watermark. Premium unlocks batch work and high-resolution export.	Pictures are transferred encrypted. The policy claims no retention for online editing.	Dedicated camp. Content marketing, ads, and simple copy updates on promo pages or social pictures, including typo fixes. Font fidelity suits style-sensitive edits.
ReWords AI	Detects existing lettering, removes it, rebuilds the background, and renders a translation or a replacement with a matching font, color, and size. It is for finished images when there is no source file. The work is done in the browser.	Purpose-built for flyers, posters, menus, and labels. The path is a short replacement rather than a scene rebuild.	Results depend on picture quality, font complexity, and background texture. Complex photographic backgrounds are best-effort. Not for IDs, invoices, or official documents.	A free first edit after sign-in. Credit packs and subscriptions cover volume and higher-resolution exports.	Cloud processing. Review the privacy terms before uploading a sensitive picture.	Dedicated camp. Fast replacement on a finished picture when the design file is gone: the everyday localization and correction case.
Textify (Storia.ai)	Mainly fixes garbled lettering in pictures a model generated, replacing wrong glyphs with a meaningful string.	Built for generated-art workflows. It can improve readability somewhat, and the replacement is one click.	It targets pseudo-text in generated pictures, not photographs of real scenes. Current results are limited. Examples still show spelling errors.	Not officially released. It is a project demo.	No public privacy policy. The work is still at a development and testing stage.	Hobbyists fixing lettering in output from DALL·E or Stable Diffusion. Immature, and not for real photos.
Baidu Netdisk AI retouching	Recognition and editing of lettering inside the drive app. Select a region and change the font, the color, or the size.	Short steps in that interface. It auto-detects regions and offers edit controls. It advertises editing in the same font format. Saving and sharing stay in the same ecosystem.	The app is required. Accuracy depends on how complex the scene is. Output quality is thinly verified in public, with little published testing.	Built into the drive app. Access may depend on a VIP tier. It is described as currently free.	An internal feature. Processing may happen on the vendor's servers under the drive's general privacy rules, including encrypted storage.	Dedicated camp. Quick replacement for people already in that ecosystem, such as ads and layout notes. Convenient, but watch the output.

The pattern in those rows is stable once you stop reading them as a single ranking. The desktop scene editor and the video platform are creative processors without a dedicated lettering editor. The browser app and the chat are friendly doors into a general edit. The deletion row is for clearing words, not for setting new ones. The font-matching web editor, the drive-app retoucher, and the browser tool for finished images are the purpose-built lettering rows. They are the ones that prioritize a font match and a short path. The on-device repair app, the background cutter, and the unreleased demo sit in the table so they are not mistaken for that job.

What the rows decide, before anyone averages them

Shipped products fall into three camps, and each camp wins on a different axis. That is the short answer. It is also why a single subscription, a single chat box, or a single erase button keeps disappointing people who expected one upload to finish every kind of wording change.

Dedicated editors lead on font fidelity and on speed. They are built to keep the original style. The web editor that imitates letterforms, the select-and-type flow inside the drive app, and the browser tool that detects, removes, rebuilds, and renders on a finished file are the three rows in that camp. You point at lettering that is already in the picture, you type, and the product tries to hold the typeface, the color, and the size while it rebuilds whatever the letters were covering. The flow feels like a word processor. The barrier is low because you are not asked to become a scene compositor. That is the camp for a discount, a date, a translated dish name, or a label correction when the design file is gone.

General generative tools lead on scene context and on creative flexibility. They look at the whole picture, not only at a line of type, so they are strong when the edit is really about the scene. Their generated lettering is often blurry, misaligned, or misspelled. They can understand that a sign exists in a street scene and still fail to draw a clean word on that sign. The desktop row can remove lettering and fill the background without an obvious seam, and the letters it invents are still not style-consistent. The chat row can add or change wording in one natural-language pass, and it still returns typos or warped glyphs often enough that a proofread is not optional. The browser row is the same split with a brush instead of a sentence: fast on ordinary graphics, weak when the ground is complex, and dependent on you to mark the region because it does not box the line itself.

Removal-only tools delete lettering cleanly and cannot put words back. The deletion row is a fill with a simple interface. It is useful. It is not the headline feature. Asking it to write the replacement is asking for a column it does not have. You leave with a clean hole and no new sentence.

The wanted feature, type new text and have it look native, is still the weakest link across the set. Removal only has to invent a surface. Replacement has to invent a surface and then invent lettering that shares the original weight, color, shadow, perspective, and texture. Those skills do not mature together. A stunning erase demo is not a relettering demo. If you remember one distinction before you pick a row, remember that one.

Do not read the split as "only the dedicated camp is allowed." Scene reconstruction, object removal, and extending a background are real jobs, and the general camp is built for them. The mistake is asking a scene model to also be a type setter, or asking a type setter to invent a new object in the background. If you need both, run them as two passes and keep the intermediate. You can throw away the bad pass without rerunning the good one.

How the six columns should be read against each other

The header is the argument. A later paragraph that seems to praise a row still has to survive the cell.

What it edits is the scope, not the slogan. Some rows edit a string they have recognized. Some edit a region of pixels and hope the letters come along. One row edits only a background and has no concept of glyphs. One row edits stills and motion and can delete a word only as a side effect. Scope decides the rest of the row. A product that cannot see a string cannot be the best font match, no matter how convincing its fill is.

Strengths are the axis that row actually wins. Scene context is a real strength on the desktop row and a real non-goal on a deletion tool. A short, word-processor path is a real strength on the dedicated rows and a real absence on the chat row. On-device editing is a real strength on the Mac repair app and irrelevant to a question about matching a logo face. Do not borrow a strength from the next row to cover a hole in this one.

Limits are where the comparison gets honest. No font match. Still in beta. No automatic boxing. Spelling that drifts. Delete only. Weak on tiny type, handwriting, and warped type. Best-effort on a photographic ground. Not for identity documents. Not officially released. An app you have to install inside one ecosystem. Those limits are not footnotes under a universal editor. They are the reason the table has eleven rows instead of one.

Price is a shape, not a score. Subscription, a free tier that can watermark, a free first edit and then packs or a subscription, a daily quota, a one-time purchase, a basic free cut-out, pay-as-you-go, a drive feature that may depend on a membership and is described as currently free, an unreleased demo. None of those cells is a quality grade. The cheapest door is not the row that keeps a typeface. I am not filling in a per-credit price, because this comparison does not have one to report.

Privacy is a data-flow column. Most of the cloud rows upload the picture. One of them may use uploads for training, with an opt-out. One says it does not keep the file, or keeps it only briefly. One caches processed content and asks you to read the license. One is mostly on the machine. The drive feature may process on that vendor's servers. The unreleased demo has no public privacy policy at all. "Local" on the chrome does not mean every stage is local. Ask which stage leaves the machine.

Best fit is who should open the row, not a medal. Professional scene work is not precise relettering. Social graphics are not identity documents. A chat prototype is not a proofing desk. A Mac repair pass is not a lettering editor. A background cut-out is preprocessing. A video platform is a video platform. A deletion tool clears unwanted words. A font-matching editor updates copy on a promo image. A browser tool for finished files is the everyday localization case when the source file is missing. An unreleased fixer is for hobbyists staring at garbled glyphs in a generated picture. A drive-app retoucher is for people who already live in that ecosystem and will still look hard at the output.

Pairs people keep collapsing into one product

The table is easy to misuse by averaging it. These pairs are the comparisons I actually used.

The desktop scene row against the dedicated lettering rows. Both can leave you with a picture that no longer shows the old word. Only the dedicated rows treat the new word as a string that was rendered, rather than as a texture the model hoped would look like language. Use the desktop row when the selection is an object, a stain, or a background that has to be extended, and plan to set any real wording yourself on a type layer afterward. Use a dedicated row when the sentence is the edit and the rest of the picture should stay. The desktop row's own best-fit cell already says it is not the tool for precise lettering replacement. Believe the cell.

The browser brush against the chat sentence. Both are general-camp doors, and both will tempt a non-designer because neither asks for a long tutorial. The brush wants you to mark the region and then prompt. The chat wants you to describe the region in language, and it may call another editor through a plugin once you are logged into that plugin. Neither one auto-matches a face the way a dedicated row does. The browser row is the better fit for a template-shaped social graphic you are willing to mark by hand. The chat row is the better fit for a rough prototype where you will throw the letters away after you have decided what the line should say. Neither is the row I would trust with a phone number.

The deletion row against every row that can type. Deletion is the mature half of the pipeline. The product only has to guess the surface that the strokes were hiding, and the description it gives — look at the surround, rebuild what was behind the text — is why those holes often look seamless. Replacement starts after that guess and adds a type problem the deletion row refuses. If the job is a watermark, a stray caption, or a number that should not be in the frame, stop on the deletion row. If the job is a new price in the same visual voice, leaving the deletion row is not a failure of nerve. It is a change of task. Doing both in one product because the marketing page used the word "edit" is how the weak link gets blamed on the strong one.

The on-device repair app against the cloud rows. The Mac app is a pleasant editor for object removal and color, and the file can stay on the machine. It does not recognize a line of type in order to replace it. Privacy that never uploads is a genuine advantage, and it does not create a font match that the product does not have. The moment a desktop app calls a cloud fill for the hard stage, the privacy column flips for that stage even if the rest of the session felt local. Ask which stage is on the machine. Do not accept the word local for a pipeline you have not split.

The background cutter against lettering work. Cutting a subject off a ground is a segmentation job. It is fast and it is narrow. It can be a useful preprocess if you are about to do manual type work on a product shot. It is not a hidden text editor, and a good cut-out does not tell you anything about whether a word on the package can be changed. I keep it in the table so the word "remove" does not get treated as one feature. Removing a background and removing a word are different masks, and only one of them is even trying to repair the surface the word covered.

The video platform against a still with a sentence on it. Motion, expansion, and inpainting across frames are a different product from a font match. A still can pass through that platform, and a word can disappear as a side effect of object removal. That side effect is not a style match and it is not a typesetting pass. If the work is a video, this row belongs in the conversation. If the work is a menu price, it does not, except as a reminder that frontier image models and lettering editors are not the same roadmap.

The unreleased generated-art fixer against editors for real photographs. Garbled pseudo-letters inside a picture a model just drew are a real annoyance, and a one-click attempt to replace them is a real niche. It is not the niche of a photographed poster, a scanned flyer, or a label shot on a table. The examples still show spelling errors. There is no public privacy policy because the project is not a released product. Hobby use on generated pictures is the whole best-fit cell. Pulling it into a production review of photographed type would be a category error.

The drive-app retoucher against the other dedicated rows. All three want a font match and a short path. The drive row lives inside one app and one ecosystem, may depend on a membership, and is described as currently free, with little public testing of output quality. The web font-matcher is the marketing-and-ads path, with a watermark on the free tier and a paid unlock for batch and high-resolution work, and it is weak when the type is tiny, handwritten, or warped. The browser row for finished images is the path when there is no source file: detect, remove, rebuild, render a translation or a replacement, first edit free after sign-in, packs and subscriptions when the volume or the resolution goes up, best-effort when a photograph sits behind the words, and out of bounds for IDs, invoices, and official documents. Same camp. Not the same contract. Pick the contract that matches the file you actually hold and the rules you actually have.

Why the table looks like that: four jobs stacked on one picture

Editing lettering in a flattened image is not one task. The letters are no longer a text box. They are pixels that happen to be readable. The result is only as good as the weakest stage, because each stage hands its mistakes forward. The pipeline has four stacked jobs: detect and OCR, inpaint, style match, and render new text. Written as a path, it runs from the input image, through text detection and OCR, through font and style analysis together with an edit mask, through an AI fill, through a new text render, and into a composite that is the edited image.

Most mainstream products stitch recognition, a fill, and a text update into that shape and hide the joints behind one button. The button does not make the stages optional. It only hides which stage failed when the picture looks wrong. The camps in the table are different choices about which stage to automate and which stage to leave to a person.

Detection has to find the regions and read them. Modern recognition combines deep learning, typically convolutional networks with sequence models such as LSTMs, and it is solid on printed type. It is weak on low resolution, on tiny fonts, on handwriting, and on busy backgrounds. Accurate detection is the foundation. A bad box or a bad string makes every later stage look like a rendering bug. Dedicated editors start by auto-boxing regions so a person can select one and edit it directly. That is a different experience from painting a loose mask and hoping the model noticed the same strokes. A wrong reading is worse than a missed box, because the editor may confidently change a word you did not mean to change. The general-camp browser row does not do this step for you. You mark the region. That single difference is why two "AI edit" buttons are not the same product.

Inpainting has to invent the pixels that were behind the glyphs. Older methods such as PatchMatch copied nearby patches. They look fine when the surround is stationary: a flat wall, a simple gradient, a repeating weave. They fail when the hole is large, when the texture is not stationary, or when a lighting falloff crosses the word. The copied patches tile, and you can still read the shape of the old word as a scar. Those exemplar methods have largely been replaced by generative models, diffusion-based or GAN-based, that try to keep lighting and texture continuous. That is a real upgrade on photographs, and it is a new way to be wrong. A fill can invent a plausible pattern that was never there. For lettering removal, plausible is not the spec. The spec is the surface that was already there, with the ink gone. A removal demo describes the step as reading the surround and rebuilding whatever sat behind the glyphs. Judge the hole by whether a person can still find the old baseline.

Mask thickness matters, and it is not a detail to leave at the default. Too tight, and a halo of the old stroke remains for the next stage to mistake for style. Too loose, and the fill eats a logo edge, a rule line, or the neighboring word. Letter-shaped holes are a hard case on purpose. They are thin, their edges are sharp, and they sit on top of the signal you wish you had observed. A flat printed sheet does not ask for that heroics, which is why so many demos choose it.

If you only delete, a successful fill is the end of the job. If you replace, the fill is an intermediate. It has to leave a surface the new letters can sit on. Ghost strokes show through antialiased glyphs. A fill that changed the local noise makes the new word look like a sticker even when the face is right. Look at the hole before you judge the word. People who only screenshot the final composite argue about the wrong stage.

Style match is its own job. New lettering should share the original typeface, color, shadow, stroke, and distortion. That is a separation of what the word says from how the word looks. Skip the separation, and the renderer either drops in a default face or asks a generative model to remember the font. Generative models are bad at remembering fonts. Meta Research's TextStyleBrush extracts a text style — font, stroke weight, warp — from a single example and applies it to new content. That is one-shot style transfer. It is a research prototype, not a product in this test, but it shows the split is real: content on one side, appearance on the other. Commercial tools approximate the split with a library match for a similar family, size, and color. Clipfly, for example, advertises editing lettering in the same font format. A library match is not a shader that reproduces a custom logo outline, a warped baseline, or a hand-painted terminal. Approximation is the right word. It can be good enough for a social graphic and obviously wrong on a wordmark.

What a style stage has to hand the renderer, if the renderer is going to be predictable, is a family you can actually draw, a size measured on the word rather than on a loose box, a color sampled from the stroke rather than from the halo, a shadow or an explicit "none," and a warp taken from the perspective of the word. If any of those is missing, the render is not style-preserving, and the interface should say so. A silent fallback to a popular grotesque is how a brand face becomes a different brand. Length is part of the problem even though it feels like layout. The new phrase is rarely the same width as the old one. Scaling to fit changes the weight you just measured. Refusal is a valid output. A pipeline that always squeezes is a pipeline that lies about fidelity.

Color sampling has its own trap. Strokes are antialiased, so a naive average of the box mixes ink with ground and returns mud. Reversed type, light letters on a dark photo, is where a sloppy sample returns the background color and the new word vanishes. Warped and logo faces are the honest limit of a library. A match can find a near weight. It cannot become a custom wordmark. When the guess is weak, the product should say so before anyone treats the export as done.

Rendering is where the two implementations stop looking alike. One asks a generative model to draw the characters. Drawn lettering of that kind rarely produces clean, readable glyphs. You get extra strokes, fused characters, and spelling that drifted, because the model does not have a character grid. It has a prior over pictures that contain something letter-shaped. That path can suggest a sign seen from across a room. It is the wrong path when a person will read a price.

The other path behaves like a word processor. Recognition produced a string. The person edits the string. A rasterizer draws glyphs from an actual font, and the composite blends them through the warp that was measured. In a purpose-built editor, clicking a region and typing a replacement makes the backend erase the old ink and imitate those letterforms with the new content. Imitation can mean "pick the nearest library face and match the color," which is honest, or "synthesize the outlines," which is research. Either way the letters are rendered, not dreamed. Spelling then fails only if the target string was wrong, which is a bug you can test, not a sample you cannot.

Composite order matters. Fill the hole on the original plate, then draw the glyphs on top. If you draw and fill in one joint sample, you are back on the generative path, and you cannot correct one character without resampling the patch. A rectangular overlay on a receding storefront is the sticker look, and no color match hides it. Shadows and strokes have to live in the same perspective as the word. A shadow that falls in screen space while the word falls in sign space is another sticker cue.

Critical strings die on the generative path in a specific way. A discount, a date, a phone number, a dosage: the reader carries a checksum in their head. A pretty wrong string is worse than a visible failure. Prefer a rasterizer that cannot misspell over a model that usually spells. When the style match is weak and you still use the generative drawer, put a person between the result and the publish button.

That stack is why the table refuses to crown one row. The deletion row automates the fill and stops. The general rows automate scene context and treat letters as part of the picture. The dedicated rows try to keep detection, a fill, a style guess, and a render in one short path. The research prototype shows a style transfer the products only approximate. None of those choices is "the AI text feature." They are different stacks wearing a similar sentence on the product page.

How the comparison was built, and what it refused to score

This is a literature review plus a comparison a second person can rerun. I leaned on official documentation and product notes, on academic papers, and on third-party reviews. The source window for that material is 2020–2026, so the review year is the last year of that window and the notes are not a retired demo presented as current. The same question, walked as a public comparison of whether these products can edit text inside an image, and whether the result survives a second look, sits beside this write-up. This page is the head-to-head. It does not replace running your own files.

The sample plan is 3 categories, about 20 images each, 60 total.

The categories are the ones that change which stage fails.

Simple printed text. Black type on white, or any clean ink on a quiet ground. This is the distribution demos already live on. If a tool cannot do this, it cannot do anything harder, and if it only does this, the demo has not left the easy zone.

Text on complex backgrounds. Street signs, billboards, words with busy artwork or photography behind them. This is the fill under stress, and it is also a detection problem when the artwork has edges of its own.

Special-style text. Handwriting, or commercial logo typefaces. This is the style stage under stress. A library match can look confident and still be the wrong brand.

Each picture uses moderately sized target lettering, not tiny lettering, so detection starts fair. I did not want a failure that was really "the stems were barely readable to a person, and every tool was punished for it." Tiny type is a separate experiment. Mixing it into this set would let a detector problem masquerade as a renderer problem. The dedicated web editor is already described as weak on tiny type. That limit can sit in its own test. It should not be the hidden reason the whole table moves.

The edit itself is fixed per picture. Either replace the selected lettering with a new phrase, or delete the lettering. Use each tool's intended method: recognition and a click, a direct replacement, or a prompt. Do not force a prompt-only tool through a click-to-edit interface it does not have, and do not refuse the automatic boxes on a tool that spent its engineering on them. You are comparing the product's path, not your talent for misusing it.

These metrics were planned. This article does not report results for any of them.

Recognition on the result. Run a standard reader on the edited region and check that the new string came out, then compute a correct-replacement rate from those checks. The rate is a method. I am not publishing one.

Visual consistency. Human raters would give a planned human visual score of 1–5 for how well the new lettering blends in tone, lighting, and sharpness. An image-similarity metric such as SSIM could compare the original background with the repaired background. No average of that ordinal score appears here, and no similarity figure appears here. If you compute similarity, compute it on the repaired region plus a ring of context. A full-frame figure stays flattering because most pixels never changed.

Subjective aesthetics. Reviewers compare before and after and judge naturalness and visible flaws. A blind side-by-side pass is optional. I am not claiming to have tallied one.

A repair footprint. Where you can, quantify the scar with color balance or texture consistency in a band around the edit. Also planned. Also not a figure in this piece.

The statistics plan matches the metrics, and it stays a plan. Per tool, the average replacement success and the average visual score, plus a variance so one lucky picture cannot define the row. Where the sample allows, a t-test or a non-parametric test would ask whether a difference between camps is more than noise. This article has no test statistic and no probability figure. Without measured data, the expectation is stated in words. Vendor claims and industry feedback point the same way: font matching in the dedicated camp is expected to land well, and a general scene fill is expected to drift when the background is complex. Read that as an expectation, not as a rate I measured and then rounded off.

Reproducible steps are part of the method, or the comparison is a mood. Log the real workflow. For a recognition editor: upload, wait for the boxes, click the region, type the replacement, download. For a desktop fill: record the selection geometry and the fill parameters. For a chat editor: save the prompt and the steps that indicated the region. Capture before and after for every scenario. Have more than one rater repeat the scoring so one person's taste is not the metric. Hold the environment as still as you can: similar network conditions, the same resolution across tools, the same target phrase on a given source. With more resources I would add type style and multiple languages as factors, and I would measure editing time and the feel of the interface. This write-up does not report those times. I will not invent a duration to make the table look more scientific than the passes were.

A note on leakage, because image comparisons usually lie here. Do not tune the target phrase after you have seen which row fails it. Do not drop a picture because one tool looked bad, unless you drop it for every tool and write down why. Do not score one row on a screenshot of a screenshot while the others received the original file. The harness is boring on purpose. Boring is what would make a later number mean something. I am not inventing that later number in this text.

What held once the easy pictures were separated from the hard ones

Automatic lettering edits inside images are not a mature single capability, and no single tool covers every need. The passes did not hand me a reason to collapse the table.

The dedicated rows are the ones that preserve font style and turn a replacement around on a short path. That matches the stack: a box, a string, a fill, a rasterizer that imitates letterforms instead of sampling them. The general rows win on image consistency and on creative flexibility, and they lack fine control of type. A scene fill can lift the old word and rebuild the ground. The letters it then invents are not style-consistent. A natural-language pass can change a line in one breath and still misspell it. Those are qualitative splits. They are not recognition rates, not similarity scores, and not significance tests.

One observation held on every row, and it maps onto the fill. Lettering on complex backgrounds — texture, lighting gradients — failed or left artifacts far more often. Printed lettering on a quiet ground came out well in almost all of the tools. If your picture is in the easy category, you are in the easy zone, and you should not describe that success as if it were the hard zone. If busy photography sits behind the words, expect a fight, and look at the hole before you accept the composite. The dedicated browser row says the same thing in its limits cell: complex photographic backgrounds are best-effort. The browser design row says it too, as weak precision on complex grounds. The finding is not a surprise hiding in one product. It is the fill stage, shared, meeting a ground it cannot see through the letters.

I am not dressing that observation up as a computed footprint. The color and texture checks in the method are how I would quantify "artifact" on a later pass. They were not run to a published figure here. The ordinal blend score was not averaged. What I will stand behind is the direction. Quiet grounds are kind to every camp. Textured grounds expose the fill. The style stage has its own direction, separate from the fill. Logo typefaces and handwriting are where imitation stops being imitation and becomes a different word in a nearby font. If the brand lives in the outline, do the change on a real type layer, or do not do it.

Spelling failures deserve a split, not a shrug. When a rasterizer misspells, the target string was wrong or the font lacked the character, and you can assert on that. When a generative drawer misspells, the sample drifted, and the next sample may drift differently. You do not patch the second bug with a prompt adjective. You route critical strings away from that drawer. The passes made the routing obvious without a rate beside it.

The unreleased row does not soften this. Its examples still show spelling errors, and it was never aimed at real photographs. A hobby fix for pseudo-text is not a counterexample to the gap on photographed type. It is a different input distribution, and it still does not spell reliably.

Which camp, depending on who is asking

If you are a content creator, the usual job is small and specific. A discount changes. A date changes. A label gets a translated line. Prefer a dedicated editor. The font-matching web flow, the drive app's select-the-text-and-type pattern, or the browser tool for finished images can hold the original style and rebuild the background on a short path. It feels like a word processor, so a coordinator can run it without booking a designer for every crop. For heavier creative changes — overall color, objects in the background, a different composition — add a general scene edit, and plan to touch up the output by hand. Do not rely on directly generated in-image lettering to carry critical information. The error mode is wrong characters that still look intentional, which is worse than an obvious hole. When the file is already flat and the task is to edit text in image on a poster, menu, or label, stay on the dedicated path and read every character before you publish. The first edit being free after sign-in is enough to judge one real file. It is not an unlimited plan. Volume and higher-resolution exports sit on packs and subscriptions. A photographic ground stays best-effort. Do not send identity documents, invoices, or official documents through that door, or through any of the automated doors.

If you are a designer, the bar is precise visual consistency, and a font match you do not control is not precise. Use a scene fill as an aid: remove the old lettering with it, then set the new wording yourself on a type layer so the family, the spacing, and the brand rules are yours. A chat product's desktop-editor extension can streamline part of that flow, especially while you are still deciding what the line should say. The browser brush can speed a prototype or an internal review. Check the pixels before they leave the review. Treat automatic replacement as an assistant, not as a type department. The assistant is allowed to be wrong. The file is not. Overall, the dedicated rows can get you a credible first composite on ordinary type. They do not retire the type layer when the face is the brand.

If you are on a legal or compliance team, the risk is privacy and copyright, and it is a data-flow risk rather than a taste complaint. Cloud services in this set — the chat, the browser design tool, the dedicated web editors, the deletion tool, the video platform — require the picture to be uploaded. Upload is a leak surface. On some of those services it is also a training-use question. Read the vendor's privacy terms. Confirm that retention, region, and authorization match the policy you already apply to customer artwork. An opt-out that exists only as a personal account toggle is not an enterprise control until you have tested that it binds the workspace you actually use. One row has no public privacy policy at all, which means you do not have terms to review. Do not send it a customer file in order to find out.

Output raises a second issue that is not the upload. A rewritten logo outline can step on the original creator's rights. A generated sentence can state a fact nobody approved, including a price or a claim. For official documents and for ID photos, do not use an automated tool to edit the lettering. The downside is a dispute, not an ugly spacing pair. The dedicated browser row already excludes IDs, invoices, and official documents. That exclusion is not a marketing apology. It is the correct scope. Compliance teams should treat it as a floor, not as a suggestion that other clouds are somehow acceptable for the same documents.

The safest overall approach is a mixed toolkit, with the original kept untouched. For a simple string change, start with recognition plus a dedicated editor. For a creative edit, or when the source file is missing and the scene itself has to change, use a desktop fill or a chat model as a first pass, then proofread. For clearing unwanted lettering, use a removal tool, and do not expect it to type. Stay critical of the output. Back up the original. Compliance teams should write a policy for image editing and for the review of generated content, including who may upload customer files and which document classes are out of scope no matter how clean the demo looked.

A policy that fits on one page is enough to start. Keep the source object immutable. Store the edited object beside it, not instead of it. Require a human read when the string is a price, a date, a name, a legal line, or anything regulated. Forbid automated edits on identity documents and on official records. Record which vendor processed the file, because the privacy review is per vendor, not per camp. None of that requires a new model. It requires knowing which row you called, what string you asked for, and whether a person confirmed the read before the file moved on.

The bottom line

The software can change pixels that used to be letters. Whether it can do that well is a different question, and the answer still depends on which camp owns the stage you needed. Dedicated editors, built to detect, clear, match, and rasterize, are the ones that take the headline feature seriously. General-purpose generators still cannot reliably draw lettering that belongs in a design. Removal tools remain good at the job their interface actually offers, which is the fill, and only the fill.

I would not ship a single button labeled as if those were one capability. I would not accept a hero screenshot on a white card as evidence about a billboard. I would not overwrite the only copy. I would not send a price or a legal line through a model that draws characters instead of setting them. The weakness is specific. It sits in the last step, where new letters have to look as if they had been printed with the old ones, on a surface the fill had to imagine. That step is still the hard part. A quiet line of print that survives is a pass on the easy category. It is not a pass on the product.