Edit Existing Text in a PDF

Before and after

Take one line of a contract: “The contractor shall pay within 30 days of the invoice date.” The number is wrong and should read 45. In most PDF software the fix is cosmetic: draw a white rectangle over 30, place a text box with 45 in it on top of the line, and hope the typeface is close enough. That is covering, not editing. The original 30 is still a live text object inside the file. Select-all still finds it, a search for the old number still lands on this page, and anyone who deletes the rectangle can read the original line again.

After a real edit the file contains one string: “The contractor shall pay within 45 days of the invoice date.” The line has been re-typeset, so the words after the changed number sit where the layout says they belong. The embedded font has been re-subset, so the glyphs for 4 and 5 genuinely exist inside the file instead of being improvised by the viewer. Nothing sits on top of anything else: one text object, one visible string, one search hit.

Everything else on the page is untouched. Other lines keep their coordinates, images keep their original data, and the file grows by a few kilobytes — the size of the new font subset and the replaced text object, not the size of a re-rendered page.

Why most PDF editors can’t do this

The reason is structural, and it explains most of the frustration people have with PDF editing. A PDF page contains no paragraphs, no sentences and no text flow. It contains painting instructions: draw this glyph from that embedded font at these coordinates, then this one, then this one. What reads as a sentence is stored as a list of glyph codes, each with its own position on the page — and the glyphs, not the letters, are the primary data.

A page stores glyphs, not words

Two consequences follow. First, the characters you see and the glyphs the file draws are connected only through the font’s internal mapping tables, which many PDFs encode incompletely; recovering the actual text from an arbitrary PDF is reconstruction, not reading. Second, fonts travel inside the file as subsets: if the document only ever printed the letters in “contractor shall pay within 30 days”, the embedded font may contain no other letters at all. Change 30 to 45 and the digits are probably available. Change Acme to Zebra and the glyphs for Z and b may simply not exist inside your file — a property of the file, not a shortcoming a better viewer can lift.

What a one-word change actually requires

To change existing text honestly, a tool has to do all of the following, every time, on every affected line:

1. Decode the run of glyphs back into characters using the font’s mapping tables, and confirm the result matches what a reader extracts when you copy from the page.
2. Re-typeset the line: measure the replacement string in the original font at the original size, then move every run of text that follows it by the difference.
3. Re-build the font subset so that every new glyph — and only the needed ones — is embedded with correct widths, encodings and the character mapping that keeps text extractable.
4. Write the objects back into the file and verify that other readers open the result and see the same text the editing app sees.

Most editors you meet in a browser stop before the first step. They flatten a rectangle over the old text and add a separate text object on top, because that requires no font work, no reshaping and no write-back risk. It looks fine in a screenshot, which is why the approach is everywhere. It is also why the result holds two texts on one line, why searching afterwards still finds the old sentence, and why the patched word often sits at a slightly wrong size or baseline. Desktop suites can do the real work; browsers almost never do, because the whole font pipeline would have to run in the tab. That is the honest answer to why editing text in a PDF is hard: the format was optimised for faithful printing, not for revising.

What PDFMason does instead

PDFMason for Android implements the pipeline above on the phone, on the file itself. During early access every feature of the app is free, text editing included — if that changes, this page will say so. Four capabilities matter in practice:

For the touch flow itself — opening a file, selecting the text, choosing what happens on overflow — see Edit PDF text on Android, which walks through the screens one by one.

What it can’t do

The limits below are stated the way we state limits everywhere: plainly, with the numbers measured on real documents. They are also the reason the feature fails with specific error messages instead of confident output. These sentences appear in our documentation and our app in the same words.

Characters the font cannot write. If the embedded font does not cover a character you type, the app refuses the edit and names the characters it cannot write. It does not draw a black box where the letter should be and call the job done.

Indic scripts and vertical text. Text editing writes Latin, CJK, Arabic and Hebrew scripts. Indic scripts and vertical text are refused before anything is written, rather than written incorrectly.

Reflow beyond the edited paragraph. An edit re-typesets the paragraph you touched, not the pagination of the whole file — text after your edit stays where the document put it.

Straight-line and arrow annotations. We tested it on real documents: it only writes correctly to 33% of them. So it’s not in v1.

Saving very large documents. A 1,136-page document takes 24–32 seconds to save with verification. It runs in the background and you can cancel it.

One boundary sits above all of these: a scanned page contains a picture of text, not text. Editing it requires OCR first, which PDFMason for Android runs on the device. What no tool can do — ours included — is edit the words of a scan directly, because there are no words there to edit.

Text editing vs. adding a text box

The table compares an overlay with rewriting the original text. Editors differ, so check the specific tool rather than assuming that a browser or an app always uses one approach. The difference can be invisible in a thumbnail and apparent when someone selects, searches or copies from the saved file.

Neither column is wrong for every job. A text box is the right tool for adding a note or a date that was never on the page. It is the wrong tool when the file has to be correct afterwards — because correct means one text object saying one thing, not two objects saying different things on the same line.

FAQ

For the step-by-step flow with screenshots, see Edit PDF text on Android.

Do it on Android

Everything described on this page — replacing whole blocks, rewriting a fragment inside a line, re-embedding the font, choosing what happens on overflow — runs in PDFMason for Android, on the phone, on the file itself. The walkthrough with screenshots is at Edit PDF text on Android.

The app is on Google Play. The download page has screenshots, system requirements and the store link.