Why flatten a PDF form before sending it (and what flattening actually does)

Before flattening, a filled field is three separate things: a value string, a widget annotation with a rectangle, and an appearance stream that draws the value. Flattening takes that appearance stream, registers it as an XObject in the page's resources, and appends a few operators to the page's content stream that position it at the widget's rectangle and paint it. Then the widget annotation and the field object are deleted, and when the last field is gone the /AcroForm entry goes with it.

The result is a file where your answers are drawing instructions in exactly the same layer as the printed labels around them. Nothing distinguishes "Marta Kask" that you typed from "Full name" that the issuer printed. The page looks identical, the text is still selectable and searchable, but there is no field left to click, clear or reset.

A form that is still interactive can lose your answers in ways that have nothing to do with bad intent. Some readers offer a Reset button that the form itself defines. Some email clients and document portals strip annotations when they generate a preview or convert the attachment. Printing pipelines that ignore /NeedAppearances print the empty template. And anyone who opens the file can change a number and forward it without leaving a trace in the document.

Flattening removes all of those failure modes at once, which is why many organisations quietly require it. If a request says "send a non-editable PDF", "print to PDF before submitting" or "the form must be locked", flattening is what they mean — and it is a better answer than printing and scanning, which throws away text quality and file size for nothing.

Generating an appearance stream means choosing a font and encoding the text with it. Most forms name one of the fourteen standard PDF fonts — Helvetica, Times, Courier and friends — which readers are allowed to substitute with whatever they have. Those fonts are used with WinAnsiEncoding, a single-byte encoding that covers Western European characters and nothing else. Ask it for а Cyrillic "К" and there is simply no code point to write.

Tools that ignore this produce flattened files with missing words, question marks or boxes where the name of the applicant should be. The fix is to embed a font that has the characters and rebuild every field's appearance with it before flattening. FormFlatten ships Noto Sans with the site, embeds a subset of it into your document, regenerates the appearances and only then flattens — so Cyrillic, Estonian õäöü and other Latin-Extended characters come out as real glyphs.

One consequence is worth knowing: a subset font contains only the glyphs you used. That is what keeps the file small, and it is harmless in a flattened document because nothing will ever be typed into it again. In a file that stays editable, the safer choice is to let the reader rebuild appearances with its own fonts, which is what the filled download asks for.

A drawn or scanned signature is an image placed on the page — legally the digital equivalent of signing a printout, and accepted by a great many organisations. It is unaffected by flattening because it is page content from the start.

A cryptographic digital signature is a different thing: it hashes the document and stores the hash in a signature field. Any later change to the file — including flattening — breaks that hash, and the reader will report the signature as invalid. So the order matters: fill the form, flatten it, and only then apply a qualified electronic signature with Smart-ID, Mobile-ID, an ID-card certificate or whatever your jurisdiction uses. Never the other way round.

Flattened pages print the same on every device because there is no appearance generation left to go wrong. They also merge cleanly. If you combine two copies of the same form — say, applications from two people — while both are still interactive, the field names collide: both files contain applicant.fullName, and most merge tools resolve that by keeping one value for both pages. Flatten first and the problem disappears, because there are no field names left to collide.

For long-term storage, flattened files are the safer bet: they depend on nothing but the page content, and a viewer in ten years does not need to understand forms at all. PDF/A, the archival profile, discourages interactive forms for exactly that reason. If you need an archival copy, flatten first and convert afterwards.

Do not flatten a form that somebody else still has to complete — a contract where the other party adds their details, an internal approval that travels through three desks, a template you reuse every month. Do not flatten your only copy: keep the filled, still-editable version, or export the values as JSON so you can refill next time in seconds.

There is also an accessibility cost. A field carries a tooltip (/TU) that screen readers announce as the field's label; flattening discards it along with the field. In a well-tagged PDF the visible text remains accessible, but in a badly made form the tooltip may have been the only description. If the document is going to someone who uses assistive technology, send the tagged, still-interactive version — or ask what they prefer.