A customer fills in a PDF request form, downloads it, and emails it back. Your reviewer needs a copy to read. The customer may still need to correct an address tomorrow. Those are different requirements, even when both files look the same on screen.
Flattening can be useful for a delivery copy, but it should not silently replace the working document. The useful question is: what must the next person be able to do with this particular copy?
Three states that are easy to confuse
A PDF may contain interactive form fields, ordinary page text, and annotations. Typing something over a blank line does not necessarily create a field that another system can read as form data.
For an existing interactive form, distinguish these states:
| State | What the next person needs | What to verify |
|---|---|---|
| Editable working copy | Correct values or continue filling | The saved file still contains the expected fields and values |
| Read-only field configuration | Stop normal field editing in a cooperating viewer | Field behavior and your viewer's handling of the setting |
| Flattened delivery copy | Read the filled appearance without using the original interactive controls | Values remain visible after reopening; the targeted controls are no longer interactive |
Read-only flags and flattening are not interchangeable. Neither is a cryptographic guarantee that a PDF cannot be altered with other software. If the requirement is to detect changes or control access, evaluate signatures, permissions, and application authorization separately.
Make the copy decision before choosing the export operation
Suppose you are building an equipment request form. The applicant enters an item code, a quantity, and a delivery note. A reviewer can send it back for changes, then approve a particular revision.
Keep a working PDF for the revision process. After approval, create a delivery derivative only if the recipient needs that format. A practical sequence is:
- Start from the intended form template revision.
- Fill values, finish the active field edit, and run the application's validation.
- Save the editable PDF as a new revision.
- Reopen that saved revision and confirm the field values.
- Make a separate derivative and flatten the intended form content.
- Reopen the derivative in the recipient's viewer and compare the visible values.
- Deliver only the verified derivative while retaining its connection to the editable revision.
The ComPDF Web form operations cover creating and filling interactive fields as well as flattening forms. The PDF component performs those document operations. Your application still decides which revision was reviewed, who can create a delivery copy, and which file a download button returns.
Use the exact API and save behavior documented for the Web SDK version installed in your project; a method copied from a desktop SDK is not automatically a Web SDK call.
Save first, then derive from that saved revision
A subtle failure happens when an application saves the working copy and creates the final copy from different document states. The screen may show the last change while the saved file still contains an earlier value.
Treat the saved working revision as the input to the delivery operation. Do not use the original template again, and do not overwrite it with the filled result. When the reviewer requests a correction, create a new working revision and regenerate the derivative from that revision.
Workflow illustration. Revision records belong to the application, not the PDF engine.
One possible application record is:
{
"submissionId": "request-127",
"templateRevision": "equipment-v3",
"workingRevision": 4,
"workingFile": "requests/request-127/r4/editable.pdf",
"deliveryFile": "requests/request-127/r4/delivery.pdf"
}
These are application-defined fields, not a ComPDF response schema. Their purpose is to let you answer a concrete question: which editable revision produced this delivered PDF? A file path or a name containing final is not approval evidence on its own.
Keep export separate from successful persistence: obtaining PDF bytes does not mean your server has stored them, authorized access, or recorded the revision.
Use values that expose handoff mistakes
Do not validate only with a short name and a selected checkbox. Use a small form that makes errors visible:
-
An identifier such as
00127. It should remain the same identifier; the application must not treat it as a number and remove leading zeros. - A zero quantity or amount, where allowed. It must not disappear because application code treats zero as an empty value.
-
An optional blank field. A blank is different from inserting a default value or the text
null. - A long delivery note. Check whether the actual viewer and field configuration show all required content, including on the flattened copy.
- Selected and unselected checkboxes. Confirm the visible state matches the saved data, rather than assuming the first radio option or default appearance is correct.
- Characters your recipients use. Include the relevant language and punctuation, then check the saved appearance.
For each case, inspect both copies after closing and reopening them. The working copy should preserve the required field editing behavior. The delivery copy should preserve the intended appearance and the intended flattening scope. Compare the content at normal reading and print sizes, not just in a tiny preview.
If the field value is correct but some text is clipped, that is still a failed delivery for a reader who needs the missing text. Revisit the field layout, font settings, or text limits before regenerating the copy.
Check what you are flattening
Form fields, annotations, and drawn signatures can travel through different operations. Flattening forms does not justify a claim that every annotation has been flattened or that a cryptographic signature remains valid.
Choose the scope explicitly, inspect the output, and test any signed-document workflow separately. Do not use flattening as redaction: text that should be removed needs an appropriate removal workflow, not simply a less interactive presentation.
Likewise, a PDF that looks filled is not proof that submission data was stored in your database. If you need structured values for downstream processing, collect and validate them deliberately before removing the controls you depend on.
Let the recipient's task decide the deliverable
Keep the editable copy when corrections, field extraction, or continued form filling are part of the workflow. Consider a flattened derivative when a recipient needs the confirmed visual form and no longer needs the interactive controls. Keep both only when the workflow has a reason for both, with access and retention rules appropriate to each.
The acceptance test is straightforward: can the next person do their job with the delivered file, and can your team trace it back to the exact working revision? Once those answers are clear, filling, saving, and flattening become deliberate document operations rather than a single ambiguous “export” button.
For the export step, follow the Web SDK document saving guide, then apply the reopening checks above to your own form and recipient viewer.
Top comments (0)