About Fill PDF form
Fill PDF form reads the AcroForm layer inside a fillable PDF and turns every field into a labelled input on the page, so you can complete a form without Acrobat. Text boxes, multi-line text areas, check boxes, radio groups, dropdowns and multi-select option lists all come through, along with the form's own rules: required fields are marked and maximum lengths are enforced as you type. When you save you choose between a flattened PDF, where values become ordinary non-interactive page content, and a fillable copy that stays editable for the next person. A full PDF editor can still alter ordinary page content, so flattening is compatibility rather than a security control. Useful for tax returns, rental applications, school permission slips and vendor onboarding packs.
Fill PDF form specs
| Price | Free ($0) — no paid tier |
|---|---|
| Account | Not required |
| Watermark | None |
| Where it runs | In your browser, on your device |
| File upload | No file is uploaded |
| Input | PDF form (1 file) |
| Output | PDF (interactive or flattened) |
| File size limit | Limited only by your device's memory |
| Offline use | May work after all required code and assets have loaded; browser caching is not guaranteed |
How to use Fill PDF form
Drop in the fillable PDF
Drop one PDF onto "Drop your fillable PDF here or click to browse". The status line reports how many fields were found and how many are filled; an XFA form raises an amber notice instead.
Fill the fields
Every field appears in the Form fields panel with its own name as the label. Required fields are marked "(required)", maximum lengths are shown, and the PDF's tooltip text sits under the input when the form defines one.
Watch the page preview
The page preview renders the document with a banner reading "Filling N of M fields", so you can confirm your edits are being registered before saving.
Choose the output format
The Output format chips are Save flattened, which is the default, and Save as fillable. The line underneath restates what each one means for the recipient.
Save the filled PDF
Press Save filled PDF. Required and maximum-length rules are re-checked first, then the file downloads as yourfile-filled.pdf or yourfile-filled-form.pdf.
Frequently asked questions about Fill PDF form
Which PDF form field types can this tool fill?
Fill PDF form handles the five AcroForm field types that hold a user value: text fields, including multi-line ones that get a proper text area, check boxes, radio groups, dropdowns and multi-select option lists. Each one appears in the Form fields panel as a labelled control, using the field's own name as the label, with the field's tooltip shown underneath when the form defines one. Push buttons and signature fields are deliberately skipped, because neither carries text you type — a signature widget needs a cryptographic operation, not a value. If a document contains none of the five fillable types, the panel stays empty and the tool says so plainly rather than offering you a download that would change nothing.
My PDF says it is fillable but no fields appear — what is wrong?
The usual cause is an XFA form, the legacy Adobe LiveCycle format that stores its fields as XML rather than ordinary AcroForm widgets. PDFChamp does not support XFA and Print to PDF does not convert XFA into editable AcroForm fields; printing may only preserve the values already visible as static page content. The other possibility is that the document only looks like a form — a scan, or an export where the boxes and lines are artwork with no interactive layer. In either case there are no supported widgets for this tool to fill.
What is the difference between saving flattened and saving as fillable?
Flattening bakes values into the page content and removes the interactive widgets, so ordinary form controls can no longer be retyped. It is not a security control: a full PDF editor can still change ordinary page content. Saving as fillable keeps the widgets live so the next person can correct a typo or complete blank fields. Flattened is the default; keep a fillable copy if you may need to edit again.
Will accented or non-Latin characters appear correctly?
Most accented Latin characters — é, ñ, ç, ü, ä and the rest of Latin-1 — are drawn with Helvetica and come out exactly as typed. If a value uses characters Helvetica cannot encode, such as Polish ł, Cyrillic, Greek, Hebrew or Arabic, the whole form switches to an embedded Unicode font before anything is written, and that font is registered in the form's own resources so a viewer that regenerates an appearance later can still resolve it. CJK and emoji are the hard limit: they cannot be drawn, and rather than quietly saving a PDF full of blank boxes the tool names the exact offending character so you can change it. A running banner counts how many of your fields currently hold non-Latin text.
Does it enforce required fields and character limits?
Both rules are read out of the PDF itself and enforced before anything is saved. A field the form marks as required shows "(required)" in its label and blocks the save with a Required message if you leave it empty — an unticked check box counts as empty, and so does an option list with nothing selected. A text field that declares a maximum length shows that limit next to its label, caps typing at it, and is re-checked on save. If anything fails, the offending fields are highlighted and the save is refused with a message pointing at them; editing a field clears its error immediately. Nothing beyond those two rules is validated — the tool will not tell you a date is implausible or a total does not add up.
Is my filled-in data sent anywhere?
The component holds typed values in page state, applies them with pdf-lib and creates the downloaded PDF in the browser. It does not post the selected document or field values to a processing endpoint or save them in local storage. Resetting or leaving clears the component state; the privacy policy covers separate site-level analytics.
Why in-browser processing matters
Every PDFChamp tool runs inside this page: the file you choose is read by JavaScript in your own browser and is never sent to a server, so nothing is uploaded, queued, or stored anywhere. That removes the upload wait, the processing queue, and the question of what happens to your file afterwards — the PDFChamp overview compares this architecture with server-side PDF tools.
Last updated