To document the steps for using PDF Overlay, record three repeatable actions in order: choose a base PDF and an overlay PDF no larger than 25 MiB each, set the overlay opacity from 0.1 to 1 while noting whether the overlay has one page or multiple, then create the file and inspect every important page before distribution or print. Documenting the process means writing down which file plays which role, which opacity value you used and why, which page-mapping rule applied, and what you checked in the final PDF. A written record turns a one-time task into a reproducible SOP that anyone on your team can follow, audit, or hand off without guessing. Because both files stay on your device, your documentation can safely name exact filenames, opacity values, and the order of operations without exposing sensitive data.
When you sit down to use the PDF Overlay tool, the real question is which details have to land in your notes for the workflow to be repeatable a month from now. That depends on what the overlay is being used for: a one-page letterhead behaves differently from a ten-page signature sheet, and the base PDF's page count, page order, and filename conventions all carry forward to the output. Writing these details down — not just remembering them — is the difference between a documented process and a fuzzy habit.
What Documenting Your Overlay Workflow Actually Means
Your documentation should answer four questions before anyone runs the tool: which file is the base, which is the overlay, what opacity was applied, and what page mapping rule was in effect. Without those four answers, the record cannot be reproduced.
Start with the file roles. The base PDF controls the output page count, page order, page boxes, and the underlying content. The overlay PDF is the layer that gets drawn on top. Recording which file served which role is the single most important line in your SOP, because swapping them produces a visibly different result and a different output filename.
Next, record the opacity value between 0.1 and 1. A value of 1 is fully opaque, which can hide the base content entirely; smaller values leave the base visible through the layer where the PDF graphics model allows. The number alone is not enough — write down why that number was chosen (for example, "0.6 so the report text stays readable under the logo").
Then note the page mapping rule. A one-page overlay repeats on every base page, which is the right behaviour for letterhead, borders, and stamp sheets. A multi-page overlay maps page 1 to page 1, page 2 to page 2, and so on, leaving any extra base pages unchanged and ignoring any extra overlay pages. This is the rule you must write into your SOP so that future runs match the original intent.
Finally, list the inspection step. Before sending the file out, every important page should be opened and visually verified. The overlay is drawn above the base artwork, so a misplaced layer or a wrong opacity is immediately visible — but only if you actually look.
The Three Steps to Record for PDF Overlay
The tool condenses the entire workflow into three browser-based actions, and your SOP should mirror that exact order so the documented process matches what the tool actually does.
- Choose a base PDF and an overlay PDF, each no larger than 25 MiB. Open the PDF Overlay tool in your browser and select the file that should define the output structure as the base. Then choose the file that should be drawn on top as the overlay. Confirm both files are non-empty PDFs and that neither is encrypted, damaged, oversized, or password-protected — the tool rejects those inputs with a visible error and will not bypass protection.
- Set overlay opacity from 0.1 to 1 and review the documented single-page or multi-page mapping rule. Enter an opacity value in the 0.1–1 range. A value of 1 is fully opaque; smaller accepted values make the layer more transparent where the PDF graphics model supports it. Before you click create, write down in your SOP whether the overlay has exactly one page (it will repeat on every base page) or more than one page (it will map page by page, leaving any extra base pages unchanged).
- Create and download the overlaid PDF, then inspect every important page before distribution or print. Click the action to overlay the PDFs. The browser embeds the overlay pages into the base document, proportionally fits each applied layer inside the corresponding base page, centers it, and serializes a new copy. The file downloads as the base filename with -overlay added before the .pdf extension, and neither input is uploaded. Open the result and check every important page — a full-page opaque layer can hide the base visually, and a dark layer can reduce readability even at partial opacity.
Each step in the list above corresponds to a line in your documented SOP. If a step is missing from your notes, the record cannot be reproduced exactly.
Page Mapping Rules to Write Down
The two mapping rules are short, but they govern the entire output. Your documentation should spell out which rule applies and why.
| Overlay page count | Mapping behaviour | Common use cases |
|---|---|---|
| Exactly one page | The single page repeats on every base page. | Letterhead, borders, stamp sheets, reusable foreground layers. |
| More than one page | Overlay page 1 maps to base page 1, page 2 to page 2, and so on. Base pages beyond the overlay count stay unchanged; overlay pages beyond the base count are ignored. | Multi-page signature sheets, paired front and back forms, per-page stamp sets. |
Each applied overlay page is scaled uniformly to fit inside the base page without cropping or stretching, its aspect ratio is preserved, and the fitted result is centered horizontally and vertically. When the two page shapes differ, blank space can remain on two sides — your SOP should call this out so a reviewer does not flag it as a bug. The tool does not offer fill-and-crop, arbitrary offsets, rotation, alignment corners, or separate width and height scaling, so any of those requirements belong in a different workflow.
Inspection Checklist for the Downloaded File
Inspection is the part most people forget to document, and it is the part that prevents a flawed file from being emailed to a client. The checklist below is what your SOP should require before any distribution or print run.
- Filename. The downloaded file should match the base filename with -overlay added before the .pdf extension. A wrong name usually means the wrong file was used as the base.
- Page count. The output page count must equal the base page count. The tool never adds or removes pages, so a mismatch means the inputs were swapped or the wrong file was loaded.
- Layer position. The overlay should be drawn above the base artwork where it is opaque. If a piece of the base is sitting on top of the overlay, the opacity or the order of files is wrong.
- Centering and fit. The overlay should be centered horizontally and vertically, scaled uniformly, with its aspect ratio preserved. Blank space on two sides is normal when page shapes differ; cropping or stretching is not.
- Readability. A dark overlay at partial opacity can reduce the readability of small base text. If the SOP targets a printed report, lower the opacity or move the dark layer behind the text in a different workflow.
- Last-page behaviour. For multi-page overlays, confirm that any base pages beyond the overlay count remained unchanged.
For a deeper post-overlay review routine, the guide on how to check the result after you overlay PDF pages walks through a verification workflow in more detail.
Limits Worth Noting in Your Documentation
Documenting what the tool cannot do is as important as documenting what it can. Future readers of your SOP should know the boundaries before they start.
First, the inputs are bounded. Both files must be non-empty PDFs no larger than 25 MiB each. Encrypted, damaged, unsupported, oversized, or incorrectly labelled files produce a visible error, and password protection is not bypassed. If a future run hits that error, the SOP should already state the workaround (reduce file size, remove the password, repair the file) so the reader does not have to invent one.
Second, the tool does not act on document structure. Interactive elements such as links, comments, form fields, scripts, attachments, and outline destinations are not copied as equivalent interactive objects by the drawing operation. The output is a visual page overlay, not a semantic merge of every document structure. A documented note that "this file is a visual layer, not a structural merge" prevents misuse later.
Third, opacity is not security. An opaque overlay can hide base content visually, but it does not delete the underlying base content from the content stream. Hiding content visually is not secure redaction. Similarly, placing a signature-looking image on a page does not create a cryptographic digital signature or establish signer identity. Document this caveat prominently in your SOP so the workflow is never used as a compliance step.
Fourth, a stale job cannot replace results made from newer file choices or opacity settings. Changing either input or opacity revokes the previous object URL and removes the obsolete download. Your documentation should mention that only the most recent result is available for download.
Documenting Visual Layering vs. Real Redaction
One of the most common mistakes a documented workflow can prevent is treating an overlay as a redaction step. When an opaque layer is drawn over a base page, the base content is still present in the file's content stream — only the visible rendering is changed. Anyone with a tool that strips overlays or that reads the underlying content stream can recover the original text, images, and vector paths.
Your SOP should therefore describe the PDF Overlay tool as a visual combination step, not a content-removal step. Use it for placing letterhead above generated pages, adding a prepared border, combining a transparent design layer with a report, or pairing corresponding foreground sheets. For concatenation, use Merge PDF; for interleaving, use Alternate Mix PDF; for generated text marks, use Add Watermark to PDF; for a drawn signature workflow, use Sign PDF. Each of those tools has its own documented procedure, and your overlay SOP should refer to them rather than trying to cover their behaviour.
If the underlying goal is to remove sensitive information from a PDF, no overlay step will achieve it. The base content must be redacted at the content-stream level, which is outside the scope of a visual layer.
If you're weighing options, How Do I Document the Steps to Use Alternate PDF Pages covers this in detail.