Free PDF Flatten Online

How It Works

1. Select or drop a PDF file above.
2. Choose which elements to flatten (form fields and/or annotations).
3. Click "Flatten PDF" to process the file in your browser · nothing is uploaded.
4. Download the flattened PDF immediately with all interactive elements converted to static content.

Why Flatten PDFs?

Flattening PDFs is essential for finalizing documents, preventing accidental modification, and ensuring compatibility across systems. When you flatten a form, all user-entered data becomes permanent and non-editable. This is critical for legal documents, contracts, completed applications, and archived records. Flattening also reduces file size slightly and ensures the PDF looks identical on all devices and applications, since no form interpretation is needed.

What Gets Flattened?

• Form Fields · Text boxes, checkboxes, radio buttons, dropdown menus, and signature fields become static text or graphics.
• Annotations · Comments, highlights, underlines, stamps, and other markup are merged into the page background.
• Field Values · Any data entered in form fields is preserved and becomes permanent page content.
• Visual Appearance · The layout, fonts, colors, and design remain exactly as they were before flattening.

When to Flatten PDFs

• Completed Forms · Flatten after filling out applications, contracts, or surveys to finalize the document.
• Legal Documents · Ensure signed contracts and legal agreements cannot be modified after execution.
• Archiving · Flatten before long-term storage to ensure documents remain unchanged and readable.
• Sharing · Send flattened PDFs when you don't want recipients to modify form fields.
• Printing · Flatten before printing to ensure all content appears correctly on paper.

Frequently Asked Questions

Will the PDF look different after flattening?

No. Flattening preserves the exact visual appearance of your PDF. All form fields, annotations, and content will look identical to how they appeared before. Only the interactivity is removed.

Can I undo flattening?

No. Once a PDF is flattened, the original form fields and interactive elements are merged into the page background. You cannot recover them. Always keep a backup of the original PDF if you may need to edit it later.

What if the PDF has no form fields?

If a PDF contains no form fields or annotations, the file will be processed but no flattening will occur. The output file will be similar to the input. You can safely flatten any PDF, even those without interactive elements.

Is my PDF uploaded to a server?

No. All flattening happens locally in your browser. Your PDF never leaves your device, ensuring complete privacy and security.

Does flattening reduce file size?

Slightly. Removing form field definitions can reduce file size by 1-5% depending on the PDF structure. However, flattening is primarily about finalizing documents rather than compression.

What's the file size limit?

The tool supports PDFs up to 100 MB. Processing time depends on file size and complexity. Most PDFs flatten within seconds.

What "PDF flatten" actually means

"Flatten" is one of those PDF-tool verbs that means several genuinely different things depending on what is being flattened, and the distinction matters because the operations succeed and fail in different ways. Form-field flattening is the operation this tool performs by default. A PDF form field, in the AcroForm sense, is a logical construct: there is a field object in the document catalog with a name like FirstName and a value like Sasha, and there are one or more widget annotations on the page that render the field visually. The widget knows what to draw because its appearance dictionary (/AP) points to a small content stream that contains the draw operators, the embedded fonts, and the text. The field and the widget are two different objects: one stores the data, the other stores the picture. Flattening reverses the relationship: the appearance stream is drawn directly onto the page's content stream as if it had always been part of the page, and the field and widget objects are then deleted. The pixels look identical, but the form structure is gone.

Annotation flattening is the analogous operation for non-form annotations: sticky notes, highlights, strikeouts, freehand drawings, text-box callouts, stamps. Each markup annotation also has an appearance stream (/AP/N) that the reader uses to draw the mark; flattening writes that stream onto the page and removes the annotation object. The visual mark stays, the ability to click, select, edit, or remove the mark goes away. This tool flattens both form fields and annotations by default; the two checkboxes above let you disable either independently if you want to keep one kind of interactivity while removing the other.

Transparency flattening is something different: the operation that takes a PDF with semi-transparent objects and converts them to a collection of fully opaque tiles that look the same when composited. PDF/A-1 archival conversion needs that step because PDF/A-1 does not allow transparency. PDF/A-2 onward allows transparency natively and skips it. This tool does not perform transparency flattening, the term overlap is unfortunate but the operations are distinct. If you need PDF/A-1 conformance, run this tool first to flatten the forms and annotations, then run a dedicated PDF/A converter that handles the transparency step.

How this tool works

This tool uses pdf-lib, the JavaScript PDF library written by Andrew Dillon and maintained as open source since 2018. pdf-lib is implemented in TypeScript and compiled to about 1.1 MB of pure JavaScript with no native or WebAssembly dependencies. It runs in any JavaScript environment, the browser tab here, but also Node.js, Deno, React Native, and service workers. The library is the de facto standard for browser-side PDF manipulation: it is used by Documenso, by several major SaaS products' PDF-edit features, and by countless internal tools and form-processing pipelines.

When you select a PDF, the browser File API hands the raw bytes directly to pdf-lib running in the page's JavaScript engine. pdf-lib parses the file into an object model, walks the AcroForm tree to count fields, exposes the count back to the page, and waits for the Flatten button. When you click Flatten, the selected options are passed to pdf-lib's form.flatten() method, which iterates over every field, regenerates appearance streams to capture the current values, copies the appearance streams onto each widget's page at the widget's rectangle, and removes the widget and field objects from the document. The resulting bytes are serialised back to a Blob which the page wraps in a download URL. No network request fires during the flatten. You can verify there is no upload: open the browser developer tools to the Network tab before clicking Flatten, run the operation, and watch for any request with your file contents. There will be none.

The AcroForm structure, briefly

When a PDF contains an interactive form, the document catalog includes an /AcroForm entry that points to an AcroForm dictionary. The dictionary's load-bearing fields are /Fields (the array of field objects, each with a partial name, a current value, a field type, and a kids array of widget annotation references), /DR (the default resources dictionary that holds fonts and colour spaces referenced by field appearance streams), /DA (the default appearance string, a one-line content stream fragment like 0 0 0 rg /Helv 12 Tf that sets default text colour, font, and size), and /NeedAppearances (a boolean flag).

The /NeedAppearances flag matters because pdf-lib's flatten respects whatever appearance is stored in each widget. When the flag is true, the reader is expected to regenerate appearance streams before display, so the streams on disk may be stale. The rule of thumb is to regenerate appearances before flattening, which this tool does for you. A field can have multiple widget annotations on different pages (useful for radio groups or recurring signature blocks); a widget can belong to only one field. The widget itself is just an annotation with /Subtype /Widget, a parent reference back to the field object, a rect for where on the page to draw, and an /AP/N appearance stream that gets drawn there.

A brief history of PDF forms

• 1996, PDF 1.2, Acrobat 3, AcroForm introduced. Form fields are PDF objects in the document catalog; widget annotations render them on the page. The model is simple, the appearance is fixed by the writer, and the data round-trips through FDF (Forms Data Format) and XFDF (the XML variant).
• 2002, Adobe acquires Accelio. Adobe inherits the XFA technology, a Canadian-developed XML-based form definition language that JetForm (later Accelio) had submitted to the W3C in 1999.
• 2003, PDF 1.5, Acrobat 6, XFA forms introduced inside PDF. An XFA form is a complete XML document embedded in the PDF as a packet. Static XFA renders the XML to a fixed layout; dynamic XFA changes layout in response to data, scripts, and user input. Dynamic XFA cannot be displayed by anything other than Adobe Reader and Adobe Acrobat.
• 2008, PDF 1.7 standardised as ISO 32000-1. AcroForm and XFA both formally part of the spec, though XFA is referenced from external Adobe documentation rather than fully specified inline.
• 2017, PDF 2.0 published as ISO 32000-2, XFA deprecated. The standard now says interactive processors that support XFA "shall clearly indicate to the user when they are interacting with an XFA form," which is a polite way of saying the format is on the way out. AcroForm remains the sole standardised PDF form format.
• 2020 onward, AcroForm is the practical standard. Most non-Adobe PDF readers no longer support XFA at all. AcroForm flattens cleanly with any reasonable PDF library because the structure is well-defined. XFA does not flatten with non-Adobe tools because the dynamic version requires a JavaScript engine and a layout engine that essentially only Adobe Reader and Acrobat ship.

The annotation universe

PDF defines roughly 25 annotation subtypes. The ones a flatten operation handles, in rough order of how often they appear: Text (the sticky-note icon with a popup window); Highlight, Underline, Squiggly, StrikeOut (the text-markup group, each with a /QuadPoints array describing the quadrilaterals to draw); FreeText (rectangular text annotations placed directly on the page, used for callouts and inline labels); Line, Square, Circle, Polygon, PolyLine (the shape group); Ink (freehand pen strokes from a digital pen or stylus); Stamp (rubber-stamp images such as "Approved" or "Confidential"); FileAttachment (an icon with a file attached); Caret (a small "insert text here" mark, often paired with Highlight); Popup (the floating window that holds the user-visible comment text, flattened together with its parent markup annotation); Widget (the form-field group, handled by AcroForm flattening rather than annotation flattening).

Each annotation type has its own appearance rules, but the flatten operation does not need to know them; it just renders whatever is in the annotation's /AP/N stream onto the page. Annotations with no /AP (a small minority, mostly malformed PDFs) cannot be flattened reliably and are usually left untouched. Link annotations (clickable URL hotspots) are technically annotations but typically not flattened by this tool: the visual indication (the underlined text) is already part of the page content and there is nothing graphical to bake in, so removing the link would only delete the click target.

Real-world workflows that drive PDF flatten

• Court e-filing through CM/ECF and similar systems. The US federal court system requires fillable PDFs to be flattened before upload to its CM/ECF electronic case-filing system. The reason is that CM/ECF stores the PDF and the form data separately, and fillable forms have been a recurring source of confusion, missing data, and field-corruption tickets. Several district courts post explicit how-to-flatten notices. Similar systems in Canadian, UK, and EU courts apply the same rule. The standard workflow is to fill the form, flatten, and upload the flattened copy.
• E-signature platforms that handle existing fields imperfectly. DocuSign and Adobe Sign both have to do something with AcroForm fields on uploaded PDFs, and the conversion to their internal signing-field representation sometimes loses data, drops alignment, or misnames fields. Adobe Sign explicitly offers a "flatten on upload" toggle to preempt the conversion errors. Pre-flattening here gives you control over what gets baked in rather than handing that decision to the e-signature platform.
• Archiving signed contracts and corporate records. Legal teams flatten signed contracts before long-term archiving so that later access to the contract does not present any opportunity to modify form data. The flatten makes the values part of the permanent page content. Equally common for HR records, completed tax returns, and any compliance document that needs to remain semantically unchanged through future reader-software upgrades.
• PDF/A archival conversion. PDF/A-1 (the 2005 archival standard) does not allow transparency, embedded multimedia, JavaScript, or encrypted content, and strongly prefers no AcroForm fields, on the theory that an archival document should not depend on a future reader implementing form semantics correctly. Flattening before PDF/A-1 conversion is the standard workflow. PDF/A-2 and later relax some of these restrictions but still prefer flattened forms for archival reliability.
• Print and print-to-PDF workflows. Some print drivers handle filled-in form fields inconsistently, especially when the PDF was filled in one reader and printed from another (Preview on macOS reading an Acrobat-filled PDF is the textbook case). Flattening before printing eliminates reader-to-reader variability: the appearance stream that was on screen at flatten time is the appearance that ends up on paper.
• Sharing a filled form when the recipient should not be able to edit. The PDF still looks like a form, but the fields cannot be cleared, the checkboxes cannot be unchecked, and the values cannot be edited. Read-only field flags exist for the same purpose, but flattening is more durable, readers cannot selectively ignore the absence of fields the way they sometimes ignore the read-only flag.

Common pitfalls and what they mean

• The output has empty fields where filled values used to be. The PDF was written with /NeedAppearances true and never had its widget appearance streams generated; the reader was regenerating them on the fly each time the file was opened, so values were visible but not persisted. The fix is to regenerate appearances before flattening. This tool does that automatically, but some other flatten implementations (including a few command-line tools) skip the regeneration and produce empty-field PDFs from /NeedAppearances true source files.
• Some fields flatten but others do not. The form is a mix of AcroForm and XFA, or pure XFA. AcroForm fields flatten; XFA fields require Adobe's tooling because the XML-driven layout cannot be rendered by other libraries. The fix is either to open the PDF in Adobe Acrobat and "Save As Other, Reader Extended PDF" to convert to AcroForm, or to accept that the XFA fields will remain interactive. Files from Canadian government services and German tax authorities are still often XFA-only.
• The fonts look slightly wrong after flattening. The form's appearance stream referenced a font by name in the /DA default appearance string but the font was not embedded; the PDF reader was substituting a system font at display time, and the flatten baked in the substitution. This produces visually correct text in a reader that has the same fallback and visually different text in a reader that does not. The fix is to flatten with Helvetica embedded, which pdf-lib does by default; in pathological cases the source PDF needs the font embedded before flattening.
• The digital signature is now invalid. By design. A digital signature is a cryptographic hash computed over the document's byte range, so any structural change (including flatten) invalidates it. If you intend to keep the signature, do not flatten. If you intend to flatten, sign after, not before. A drawn signature image is just a graphic and survives flattening intact, but it never carried cryptographic verification in the first place, only a visual claim.
• The flattened PDF is the same size or larger than the original. Flattening sometimes increases file size. The embedded fonts that the appearance streams reference now have to be included in the page resources rather than as form defaults, and pdf-lib does not deduplicate font subsets across pages aggressively. The difference is usually small (under 10 percent), but it is not always a reduction. The point of flattening is structural, not compression. For size reduction, run the flattened PDF through PDF Compress.
• The form fields preview fine but disappear after flattening. The fields had /F flag bits set marking them as Hidden or NoView (PDF spec annotation flags). Hidden fields by definition have no appearance to draw, so flattening them produces nothing on the page. This is correct behaviour but surprising if you did not know the fields were hidden. Check the PDF in Adobe Acrobat's form-edit mode to see which fields were marked hidden.

Browser-only versus cloud flatten

Every cloud PDF-flatten service (Smallpdf, ILovePDF, PDF24 web, Adobe Acrobat Online, Sejda, DocHub, and a dozen smaller ones) uploads your PDF to the operator's servers, runs the flatten there, and serves the flattened copy back as a download. The PDF transits the public internet encrypted with TLS, sits in the operator's storage for a window ranging from minutes to days depending on the operator, gets flattened by the operator's PDF library running on the operator's infrastructure, and is then deleted. Privacy policies generally commit to deletion within hours to one day, TLS in transit, and (for the larger operators) ISO/IEC 27001-certified infrastructure. The operators have commercial reasons to honour those commitments. They also have logs, backup snapshots, and incident-response data flows that are not, in the general case, covered by the deletion commitment.

This tool does not upload the PDF. The pdf-lib code runs in your browser tab, receives the file bytes through the File API, performs the flatten in the JavaScript engine, and returns the flattened bytes as a Blob to the same tab. You can prove there is no upload: open the developer tools to the Network tab before clicking Flatten, run the operation, and observe that no requests fire with your file content. The pdf-lib code was loaded once from a CDN at page load and is cached by the browser; the flatten operation makes no further network requests. The trade-off is feature scope: cloud services often bundle OCR, Word/Excel conversion, or aggressive compression alongside the flatten. The browser-side flatten here does just the flatten. For OCR or format conversion, the cloud services are the right call; for a sensitive document where the privacy posture matters, the browser is.

More frequently asked questions

What form types does this tool handle?

AcroForm in all its varieties: text fields, checkboxes, radio buttons, dropdowns, list boxes, push buttons, and signature fields (the visual widget, not the cryptographic signature). XFA forms are not supported because XFA's dynamic layout requires Adobe's proprietary JavaScript and layout engine. If your form is XFA-only, the flatten will succeed but leave the form interactive; opening the PDF in Adobe Acrobat and saving as Reader Extended PDF converts most XFA forms to AcroForm equivalents that this tool can then flatten.

Can I flatten just one page or just one field?

No. This tool flattens the whole document. Selective flattening (one field at a time, or one page at a time) requires Adobe Acrobat Pro or a developer library called from a custom script. For most workflows the whole-document flatten is what you want anyway, since "some fields static, others editable" is rarely the intent.

Does this preserve bookmarks, metadata, and attachments?

Yes for bookmarks (the document outline), document metadata (title, author, subject, keywords, creation and modification dates), embedded files and attachments, optional content groups (layers), and tagged-PDF accessibility structure for non-form content. Form-related tags are removed along with the fields, which is the expected behaviour for flatten. Hyperlinks survive when "flatten annotations" is unchecked; when both options are checked, link annotation hotspots are also removed (the visible underlined text remains).

What about password-protected PDFs?

Flatten cannot run on an encrypted PDF: pdf-lib needs to read the form structure, and reading is gated by decryption. Unlock the PDF first with PDF Unlock, then flatten. If you want the flattened output to be password-protected, run it through PDF Protect afterwards. The three-step unlock, flatten, protect is the standard workflow for "finalise and re-secure" archival pipelines.

Is this the same as printing to PDF?

Practically similar, structurally different. Printing to PDF rasterises or re-imposes the page through the operating system's print pipeline, which usually flattens fields as a side effect but also re-encodes images, re-embeds fonts in different subsets, and sometimes changes page size or margins. This tool's flatten operates on the PDF object structure directly, preserving the original images, fonts, and page geometry exactly. Use print-to-PDF when you want a fresh rasterised copy; use flatten when you want the original PDF with just the form structure removed.

Is there a desktop or command-line equivalent?

pdf-lib runs in Node.js (npm install pdf-lib) and the flatten call is the same: await form.flatten() followed by await pdfDoc.save(). For command-line, qpdf has a partial equivalent (qpdf --flatten-rotation --generate-appearances) that handles appearance regeneration but not the form-removal step; pdftk's flatten operation does the removal but skips appearance regeneration. Adobe Acrobat Pro's "Flatten Fields" menu item handles both steps natively and is the reference for behaviour parity.

Related Tools