Watermark Every Page of a PDF at Once
Apply a watermark, a stamp, a header or Bates numbering across a whole document in one go — in the editor or with one API call. One save, one operation, however many pages.
Marking a document is almost never a one-page job. The draft watermark goes on all of it. The disclosure bundle gets numbered from the first page to the last. The footer with the matter reference belongs on every sheet, not the one you happened to be looking at.
PodPDF’s editor now asks the question directly: this page, or all pages?
In the editor
Every change that can sensibly cover a document offers the choice — watermarks, text, headers and footers, rotation. Pick “All pages” and one change covers the lot.
It defaults to this page, deliberately. The editor is a page-by-page walk, and nothing should affect more of your document than you were looking at unless you say so. Applying to everything is one click, but it is a click you make on purpose.
Bates numbering never needed the toggle — it has always numbered the whole document, because that is the only thing sequential numbering can mean.
What it costs
Nothing extra. A save is one operation however many pages it touches. A watermark across 200 pages costs exactly what a watermark on one page costs, and so does a document-wide rotation.
That is worth saying plainly because per-page pricing is the usual arrangement elsewhere, and it changes how you use the tool: there is no reason to be frugal about which pages you cover.
In the API
Leave pages out and the change covers every page:
curl -X POST https://api.podpdf.com/pdf/edit \
-H "X-API-Key: $PODPDF_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"source_key": "pdf-uploads/…",
"recipe": [
{ "op": "watermark.text", "text": "DRAFT", "rotation": 45, "opacity": 0.15 },
{ "op": "header_footer", "text": "Acme v Byrne — {page} of {pages}" }
]
}'Name pages and it covers only those:
{ "op": "watermark.text", "text": "DRAFT", "pages": ["p0", "p4"] } // by page id
{ "op": "watermark.text", "text": "DRAFT", "pages": "1,5-7" } // or by numberPage ids are the safer form when a recipe also removes or reorders pages — an id always means the
same physical page, whatever happened earlier. POST /pdf/inspect returns them.
Order matters, and it is handled for you
Combine a document-wide change with a structural one and the order stops being an implementation detail.
Number a five-page bundle and remove page 3. Number first and you get 1, 2, 4, 5 — a bundle with a gap, which for a disclosure list is a real problem. Remove first and you get 1, 2, 3, 4.
The editor applies changes in three passes so this comes out right without you thinking about it:
- Marks and edits — watermarks, text, rotation, metadata
- Structural changes — deletions, reordering, keeping a subset
- Numbering — Bates and any header using
{page}or{pages}
So numbering always sees the document as it will actually be. {pages} counts the pages that
survive, not the ones you started with, and a stamp on a page you also delete is simply discarded
with the page rather than erroring.
Through the API you control the order yourself — operations apply as written — so if you are assembling recipes by hand, put structural changes before anything that numbers.
Checking before you commit
POST /pdf/edit/preflight takes the same recipe and reports which pages each change resolved to,
without writing anything. For an all-pages change on a five-page document you will see
resolved_pages: [1, 2, 3, 4, 5], and for numbering you get the first and last values plus the
number the next document would continue from.
It is free, so there is no reason not to look first.
Limits
One document at a time, up to 200 pages and 150 MB, with up to 200 changes in a single save. Longer documents get split first, then edited in parts.