Find and Replace Text in a PDF
Searches every page of a file in the package for a list of strings and writes one replacement value over every match — available in the pre-bid workflow.
Overview
A document that arrives already filled in carries values that were right when someone typed them and are wrong by the time you need them. A date signed three weeks ago. A file reference that has since changed. The same stale value usually turns up in more than one place, and often written more than one way — a date abbreviated at the bottom of the form and spelled out further up.
Fixing that by hand means opening the file, hunting down every occurrence, and hoping you did not miss the one at the bottom of page nine. This tool takes a list of the strings to look for and one value to put in their place, goes through every page of the file, and writes that value over every match it finds. It reports how many matches it wrote over.
What it does is closer to correction fluid than to editing. Each match is covered and the replacement drawn on top of it, at the size and colour of the text underneath when the string you gave appears on the page in exactly the case you typed it. The letterforms are not carried over — the replacement arrives in a standard font rather than the document's own. And the covered text is still in the file: hidden, not removed.
What It Does
| Capability | What it means for you |
|---|---|
| Every page searched | The whole file is gone through, so an occurrence in a footer or halfway down an inner page is found along with the obvious ones |
| Several spellings, one value | One call takes a list of strings to find and a single value to replace all of them with, which is what collapses a date written three different ways onto one date |
| Size and colour carried over | Where the string appears on the page in the case you typed it, the replacement is written at the size and colour of the text it covers |
| Reaches text that is not a field | It works on what is printed on the page, so boilerplate, headings and reference numbers set into the document are all in range |
| A count comes back | The call reports how many matches it wrote over, so zero tells you the string you searched for is not on the page |
When the Agent Chooses This Tool
One of the three agent workflows registers this tool: pre-bid packages. The appraisal and coating QA workflows cannot call it at all.
Inside a pre-bid run it has a single assigned job, and the instructions are specific about it. The invitation to bid comes back from the contractor already filled in and signed, dated whenever they signed it, and the finished package has to carry the current date instead. So the run is told to:
- Read the file's page previews first. Inspect an Attachment returns the beginning and end of each page — which is where a signature date sits — and the date to be corrected is found there rather than guessed.
- Collect every string that spells that same date. The instruction is to gather all the format variants rather than settle on one, because the same signature date can be written as MM/DD/YY in one place and M/D/YY or MM/DD/YYYY in another.
- Make one call, with the current date as the replacement. That date is supplied to the run, and inventing one is forbidden in as many words.
- Skip the step entirely when no signature date turns up in the previews, or when every variant found already reads as the current date.
That is the whole of it. A pre-bid run is expected to make this call once, or not at all.
Inputs and Outputs
Takes: a file already in the package, a list of strings to search for, and one value to write over all of them.
Returns: the number of matches written over. The corrected file is not handed back as a separate document — it takes the place of the one in the package, and that is the version everything downstream uses.
A count of zero means nothing matched: either the string is not on the page as it was searched for, or the page carries no text to search.
Example
An invitation to bid comes back from the contractor already filled in. The signature block near the bottom of the second-to-last page is dated 07/13/26, and the same date is written out further up the form as 07/13/2026. The package is being produced on 26 July.
The page previews are read, both ways the date is written are collected, and one call goes out: look for "07/13/26" and "07/13/2026", write "07/26/26". Two matches, two writes, one call.
Two things follow from there being a single replacement value. Both places now read "07/26/26", including the one that used to spell the year in full — one value goes in everywhere, so the format is levelled along with the date. And the strings have to be specific: "26" or "/13/" would each match inside unrelated numbers all over the form, and every one of those would be written over too.
Limits
- The text has to be text. Words that exist only as pixels in a scan have nothing to search, and the call comes back having replaced nothing.
- The text it replaces is still in the file. A match is covered and the new value written on top; the original is not deleted. Copy the text out of the corrected document, or search it, and the superseded value is still there — which is also why running the same correction a second time finds it again and adds another copy of the replacement.
- The typeface is not the document's. Size and colour are carried over when the string matches the page in the case it was typed; the letterforms never are. In plain body type the difference is easy to miss, in a distinctive one it is not.
- Case is ignored, and matches can be partial. A search for a name also matches those letters inside a longer word, whatever the capitalisation. Where it matches in a different case from the one searched for, the size and colour are not carried over either — that replacement lands in black at an approximated size. Naming the fullest distinctive string is the defence.
- Nothing is re-typeset. A replacement longer than what it covers runs past it and prints over whatever sits alongside; nothing reflows, re-justifies or moves out of the way. Similar-length or shorter text is safe.
- A phrase broken across two lines is written twice. Both halves of the split count as matches, so the full replacement lands on each of them and the reported count goes up by two.
- Characters beyond the standard font come out as a dot. Accented Latin letters are fine, and so are the pound, yen and cent signs; a long dash, the euro sign, a Greek symbol or non-Latin script is substituted silently, and the call still reports the replacement as made.
- On a document whose fields are still live, the field keeps its value. This reaches what is printed on the page, not what a form field holds.
- It is a correction tool, not an authoring tool. Adding text that isn't there yet is Append Text Lines to a Page.
FAQ
Does this work on scanned documents?
Only where the words are real text. Words that exist purely as part of a scanned image can't be found, and the call comes back having replaced nothing.
What if the new text is longer than the text it replaces?
It runs past what it covers and prints over whatever sits next to it. Nothing holds the replacement to the original's width and nothing reflows to make room, so a short code swapped for a full description will collide with its neighbour. Replacements of similar length or shorter are safe.
Will the replaced text look different from the rest of the page?
In one respect, yes. Size and colour are carried over when the string matches the page in the case it was typed, but the letterforms are not — the replacement is drawn in a standard font rather than the document's own. In plain body type that is easy to miss; in a distinctive or branded typeface it is not. Worth a look at the corrected pages.
Can I fix several different things in one go?
Not several different things. One call takes a list of strings to look for but a single value to put in their place, so it handles the same value written several ways — a date in three formats — rather than a name, a date and a file reference together. Unrelated corrections are separate calls.
Why not just re-fill the form instead?
For anything held in a form field, that is the right route: this does not change a field's value. On a document whose fields are still live, the field goes on holding what it held. What this reaches is text printed on the page — boilerplate, headings, reused template content.
How do I know it replaced the right thing?
The call reports how many matches it wrote over. Zero means the string you searched for is not on the page. A number higher than you expected usually means the string also matched inside something longer, or that one occurrence was split across two lines and counted at both. Reading the page previews first is what makes the string right.