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. Text editing is a paid feature. Reading, annotating and the page-level tools in the app are free; replacing original text objects is not. 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.

Checkbox and radio-button form fields. Checkbox and radio-button form fields are marked unsupported in the app. We can change them in memory but the change doesn’t survive saving, so we don’t pretend otherwise.

Non-Latin form fields. Filling non-Latin text fields can produce a file that appears blank in other readers. The app warns you per field.

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 as a paid feature. 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 is the whole argument in one screen. The left column is what most editors — and every browser tool we know of — do when you “edit” a PDF. The right column is what replacing the original text does. The difference is invisible in a thumbnail and obvious the moment someone selects, searches or copies from the 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. Text editing is a paid feature; reading, annotating and page-level tools are free.

The app is not released yet. The download page carries the current status and the waitlist — one email when it ships, nothing else.