A filled form is a claim; a flattened form is a record
Form fields and annotations are living things inside a PDF: values can be retyped, checkboxes flipped, comments edited or deleted by anyone with a viewer and a motive — or, more commonly and more dangerously, by accident. The application you submitted, the inspection checklist you signed off, the marked-up proof you approved — as long as their contents remain editable fields, their evidentiary value quietly decays. Flattening ends the discussion: it bakes every field's appearance and value into the page content itself, after which the document says what it says, permanently, in every viewer on earth.
FlatPage performs that finalisation with an auditor's habit: inventory first. Before anything is flattened, the tool lists every form field with its type and current value, and counts annotations page by page. You see precisely what is about to become permanent — the mistyped date, the field somebody left blank, the stray comment — while correction is still possible. Flattening blind is how errors become records; the inventory is the tool's conscience, and it is mandatory by design.
What flattening does, mechanically
A form field displays through an appearance stream — the little picture of its value that viewers draw into its rectangle. Flattening merges those appearance streams into the page's own content and deletes the field definitions, so the value's picture remains but the field, as an editable object, ceases to exist. Annotations receive the same treatment under the full scope: their appearances are accounted, then the annotation layer is removed from the saved copy, leaving pages that show exactly what was approved and nothing that can be peeled back.
The verification is built into the result: after saving, FlatPage reloads its own output and counts the fields remaining, reporting the number in plain sight. Zero is the expected answer, and the tool says so. That self-check embodies the difference between a tool that performs an action and a tool that confirms an outcome — for an operation whose entire purpose is finality, the confirmation is not decoration.
Choosing scope: forms only, or everything
Forms-only flattening suits documents still in conversation: the application your reviewer may annotate further, the checklist that returns for comments each cycle. Fields lock — the data is safe from casual alteration — while comments, highlights and markups remain live objects others can add to and discuss. It is the right scope for collaboration's middle chapters, where data has settled but dialogue has not.
Full flattening is for endings: submissions, filings, signed-off proofs, issued certificates, archived records. Everything becomes page, nothing remains negotiable. The corollary discipline is to keep an unflattened master whenever there is any chance the document's data must change — flattening is deliberately one-way, and the correct professional pattern is master editable, distribution flattened. FlatPage never touches your original file, so the master survives by default; only the copy you download is final.
How to flatten a PDF, step by step
Load the file and run the inventory — read it, do not skim it. Check each field's value as listed: the flatten will preserve exactly what the inventory shows, including the typo you were about to make immortal. Confirm annotation counts match your expectation; an annotation you forgot existed is about to become permanent ink. If anything is wrong, fix it in the source form first (FieldFill completes fields beautifully) and re-inspect.
Choose the scope by the document's destination — forms-only for continuing collaboration, full for anything leaving your control — then flatten and download. The status line reports fields remaining in the output; expect zero. Open the flattened copy and click where a field used to be: nothing should respond. That small, anticlimactic test is the sound of a document becoming a record.
Where flattening is standard practice
Submission pipelines flatten by default: application portals, court e-filing, journal systems and tender platforms either flatten on receipt or instruct submitters to arrive flattened, because a fixed document processes identically in every system downstream. Print workflows demand it too — a form field that a pre-press RIP ignores prints as an empty box, the classic flattened-too-late disaster that flattening early prevents entirely.
Archiving is the quiet third case. Records retained for years must open identically in future software that may handle fields and annotation versions differently; a flattened file's appearance is self-contained, depending on nothing but the PDF standard itself. Institutions flatten on ingest for the same reason museums fix pigments: the artefact's future readability should not depend on the survival of the machinery that made it editable.
Privacy: final copies of personal records
The documents people flatten — submitted applications, completed claims, signed checklists — concentrate personal data precisely because they are complete. FlatPage inventories and flattens inside your browser tab; the file and its values never leave your device, and the inventory exists only on your screen. Nothing is uploaded, logged or retained.
Local processing pairs naturally with the flattening workflow's rhythm: inspect, correct, re-inspect, flatten, verify — a loop that would be miserable through an upload queue and is effortless on your own machine. Finality deserves that unhurried loop. The last version of a document you will ever make should be the most carefully checked one, and the checking should cost you nothing but attention.
A finalisation checklist for records that matter
Before flattening any record, walk the checklist professionals use: every field's value read aloud against its source, totals re-added once, names spelled as on the identity documents they accompany, and the document's date confirmed as the filing date intended. Confirm the recipient's format demand — some systems want the live form's data, most want the fixed record — because flattening for the wrong audience means refilling, not unflattening. Name the pair clearly: the master carries '-master', the record '-final', and neither is ever overwritten. Store the final in the records location, not the working folder; finality is also a place. With those habits, flattening stops being a button and becomes what it should be — the moment a document stops being drafted and starts being true.
Frequently Asked Questions
What exactly does flattening remove?
The editable objects — form field definitions and (at full scope) annotations — are removed after their appearances are baked into the pages. The document looks identical; it simply cannot be edited as a form any more.
Can flattening be undone?
Not in the flattened copy — that permanence is the point. Your original file is never modified, so keep it as the editable master and distribute only flattened copies.
Why inventory before flattening?
Because flattening preserves values exactly as they are — including mistakes. The inventory lists every field's current value and all annotation counts, so you can correct errors while correction is still possible.
What is the difference between the two scopes?
Forms-only locks your field data while leaving comments and markups live for continued collaboration. Full scope finalises everything — the right choice for submissions, filings and archives.
How do I know the flatten worked?
FlatPage reloads its own output and reports how many fields remain — expect zero — and you can confirm by opening the copy and clicking a former field: nothing will respond.
Is my document uploaded to a server?
No. Inventory and flattening run entirely in your browser; your completed forms — and all their personal data — stay on your device.