Short answer: a PDF has a real form layer (AcroForm fields) only if the author created one. If it does, this browser PDF form filler fills text boxes, checkboxes, radio groups and dropdowns, and saves a file where the values stay editable — nothing is flattened. If the "form" is just a scanned picture of paper, there is no form layer and no filler can magically create one. And one honest limitation up front: this tool refuses non-Latin text values (standard PDF form fonts carry no Chinese/Japanese/Korean glyphs) instead of saving garbage — the details are below, verified with real files.
The sample form, and how to re-check every claim
We generated an original synthetic AcroForm with one field of each common type, filled it in the live tool, downloaded the result, and re-opened it field by field. The exact files are below — you can reproduce the whole walkthrough, including the refusal cases.
- Sample AcroForm: 3 text fields (one limited to 10 characters), radio group, dropdown, checkbox, one read-only field — Download sample · 14047 bytes
- The actual tool output after our fill — re-open it and check the values yourself — Download sample · 12699 bytes
- Counter-example: a form that is only a picture (no form layer) — Download sample · 13693 bytes
- Counter-example: password-protected PDF (demo password: yysi-demo) — Download sample · 14678 bytes
Two kinds of "PDF form" — the 10-second check
| Interactive form (AcroForm) | Scanned/paper form | |
|---|---|---|
| What it is | Real field objects defined by the author | Just an image of a page |
| How the tool reacts | Lists every field with name and type | "No fillable AcroForm fields were found" |
| Can any filler fix it? | Yes — that is the tool's job | No — fields would have to be drawn in first (a different job) |
| Our test result | 6 of 6 fillable fields saved correctly | Refused honestly with the no-fields message |
Quick self-check in any reader: click on the line where you would type. If a blue/purple highlight box appears (or the cursor turns into a text caret), the field layer exists. If nothing reacts, you are looking at a picture — printing and hand-writing, or software that adds new fields, is the honest next step.
Filling the sample, step by step
- Open the tool and add the PDF. Drop event-registration-form.pdf onto the form filler. It runs locally in your browser; files are not uploaded. The field list appears immediately: 7 fields, 6 of them fillable, one marked read-only.
- Fill the text fields. Each field shows its own maximum length if the form defines one. We typed a 17-character code into the 10-character field — typing stops at 10 (
YYSI-DEMO-), because the tool enforces the limit the form author set rather than letting you type a value it would have to truncate or reject later. - Set radio, dropdown and checkbox. Radio groups and dropdowns become normal web controls. We picked
Pro, changed the country from the preselectedSingaporetoUnited Kingdom, and ticked the conduct checkbox. - Skip what is read-only. The
office_notefield ("REV-2026-1111") is flagged read-only by the form itself; the tool shows it but gives no input. That matches how desktop readers behave. - Save and re-open. Press Save filled PDF. The note reported "5 of 6 fields set" on our first pass (see the length limit below) and "6 of 6" behavior is reachable within the form's own limits — the downloadable
filled-final.pdfis the actual output. Re-open it: every value is there, the radio is onPro, the checkbox is ticked, the read-only field is unchanged. The values are still editable — the tool does not flatten the form.
What gets refused — deliberately
| Case | What the tool does | Our verified result |
|---|---|---|
| Chinese/Japanese/Korean (any non-Latin) text | Refused by name before saving; the field stays empty | Typed 张三 into the name field → "0 of 6 fields set" + the two offending fields named; both fields empty in the saved file — no mojibake, no corrupted output |
| Value longer than the field's own maximum | Rejected at save (typing is already capped in the box) | A 112-character note into a 100-character field was the one refused field in our first pass |
| Password-protected PDF | Refused when loading | encrypted-form.pdf → "This PDF is password-protected and cannot be filled here." |
| Scanned image "form" | No fields found — nothing to fill | scanned-paper-form.pdf → "No fillable AcroForm fields were found in this PDF." |
The non-Latin refusal exists because standard PDF form fonts (like Helvetica) simply have no Chinese glyphs — the underlying library documents this exact limitation (pdf-lib repo, checked 2026-11-11). A tool that "fills" Chinese into such a field anyway produces a file that shows garbage in the reader. Refusing and naming the fields is the safer failure. If you must enter Chinese into such a form, use a reader that embeds CJK fonts for form filling — free Acrobat Reader does (checked 2026-11-11) — or ask the form author for a version with proper fonts.
Limits of this tool
- One PDF at a time; a second file is declined with a clear note.
- AcroForm PDFs up to 50 MB and 100 pages.
- Text values use the form's standard fonts — Latin-only, as tested above.
- The tool fills and saves; it does not create forms, add fields, or flatten them. For a scanned paper form there is honestly nothing it can do.
- Everything runs in your browser tab — the PDF never leaves your device; only anonymous usage counters are recorded.
FAQ
| Question | Answer |
|---|---|
| Will the other side see my values if they open it in another reader? | Yes — values are stored as real form values with generated appearances, which is the standard mechanism. |
| Can I re-edit the file later? | Yes, in any reader that supports forms — the form layer is preserved, not flattened. |
| Why is my long sentence visually cut off in the box? | The value is stored completely (our 87-character note read back in full); a single-line box just cannot display it all at once. Re-open the PDF and click the field to see the whole text. |
| Is my uploaded form stored on a server? | No upload happens — filling runs in the browser. Only anonymous counters (tool name, success/failure, rough size range) are recorded. |
Related: if your PDF's problem is the opposite — text you cannot extract or copy — read why text extraction fails and when OCR is needed.
Sources & verification
- pdf-lib — the open-source library this tool uses to read and fill form fields (official repo) — Sources checked 2026-11-11
- Adobe Acrobat Reader (free) — for forms that need non-Latin text or e-signatures — Sources checked 2026-11-11
Sources checked Library capability statements come from the official pdf-lib repository (checked 2026-11-11). Every fill/refusal result in this guide is YYSI's own measurement from 2026-11-11: an original synthetic AcroForm sample was filled in the live YYSI tool, the downloaded file was re-opened and inspected field by field with a PDF library, and the scanned/encrypted counter-cases were reproduced in the same tool. The sample form is original synthetic artwork, published for reuse.
Read our editorial standards or send corrections to [email protected].