Fillable Word Document: Build One That Works

You create a fillable Word document by enabling the Developer tab, inserting native content controls such as plain text fields, check boxes and drop-down lists, labelling each field, protecting the form, and exporting to PDF with accessibility tags preserved. The important distinction is that a form must behave like a form, not merely look like one.

You've probably seen the failure first-hand. You send a proposal, application or questionnaire expecting a quick reply, then receive a static attachment with answers typed in random places. The “fields” were underscores, shaded cells or text boxes that never worked properly. A short request turns into a chain of emails explaining where the recipient should type.

I'm Cameron, co-founder of LiveDocument, and I've sent a lot of decks, proposals and one-pagers into inboxes. The document rarely fails because it looks bad. It fails because the recipient can't confidently complete it.

Most fillable forms are just paper with underscores

A line under a question looks like a field. It isn't one.

Underscores, manually drawn lines and shaded table cells provide no dependable input behaviour. The recipient may click beside the line, type over the label or move the layout accidentally. On the sender's side, the returned file can be difficult to read, compare or process.

That gap matters in ordinary business work. A proposal might ask for a start date and selected package. A contract may need a fixed reference number alongside editable customer details. An application could require a mixture of free-text answers, dates and controlled choices. Each field needs an intended behaviour, not just a visual position.

Practical rule: If you can't complete the document with the mouse and keyboard in the way you expect a recipient to, it isn't finished.

Word forms remain common because they use a familiar Microsoft Office application and can be completed without specialist form software. The State of Maine's accessibility guide calls Word forms the most common type of form in state government, and notes that they often don't take advantage of Word's fillable-field and accessibility features.

A digital-looking document can still behave like a sheet of paper.

The fix is to build the input layer properly, then test it independently from the visual design. A sound form gives every response location a real control, a clear label, predictable navigation and sensible protection. Only then should you think about conversion or distribution.

Enable the Developer tab and insert content controls

Word hides its form-building tools until you enable the Developer tab. In the desktop app, open File, choose Options, select Customize Ribbon, tick Developer under Main Tabs and select OK. On Mac, open Word's preferences, choose Ribbon & Toolbar, select Developer, then save the change.

Write the labels first. Then place the cursor where the answer should go and choose the matching control from Developer > Controls. Microsoft's explanation of content controls in Word covers the field mechanism intended for templates, forms and ordinary documents.

Use the field type that matches the answer:

Plain Text Content Control: Names, job titles, reference details or short answers.
Rich Text Content Control: A response that may need formatting or a longer paragraph.
Check Box Content Control: Independent yes or no choices, acknowledgements or optional selections.
Date Picker: Contract dates, event dates or review dates where consistent entry matters.
Combo Box or Drop-Down List: Department, status, jurisdiction or contract type when the answer should come from a controlled set.

Select each control and open Properties. Give it a meaningful title, add useful placeholder text and configure the permitted values where relevant. “Click here to enter text” is better than an empty box, but “Customer legal name” is better still. The label should make sense on screen and to assistive technology.

A drop-down is often the better business choice because it prevents avoidable variations such as “In progress”, “In Progress” and “progress”. Controlled answers make returned documents easier to review. The exception is a form that must be accessible: Word's drop-downs have limited assistive technology support, so see the accessibility notes below before you use them.

Protect the form and lock the right fields

Protection keeps the document's fixed structure separate from the recipient's answers. Without it, a user can overwrite an instruction, delete a control or shift a table while trying to fill in one field.

I normally leave a form unprotected while building it. That makes it easier to adjust labels, resize controls and repair the reading order. Protection belongs near the sharing stage, once the structure has been checked.

Word gives you more precise options than locking the entire document. In a control's properties, Content control cannot be deleted lets the recipient edit the value while keeping the control in place. Contents cannot be edited keeps the value fixed, although the control itself can still be removed. Microsoft describes these settings in its guidance on editing and protecting Word templates.

Use the setting according to the job:

Keep customer details editable, but stop the field itself being deleted.
Lock a pre-filled company name, reference number or standard clause when it must not change.
Leave instructions, headings and labels outside the editable response areas.
Protect the complete template when repeated users should only fill fields.

For broader protection, use Restrict Editing and allow only form filling. A password can prevent layout changes, but don't protect the file while you're still diagnosing accessibility problems. An unprotected .docx is easier to inspect and repair.

If your process involves a secured file, keep a working copy separate from the distribution version. If a protected file has already gone out and needs updating, my guide to changing a secured PDF covers it.

Export to PDF and keep the tags

A Word file and a PDF are different deliverables. Saving a document as PDF doesn't automatically create an interactive PDF form, and a control that works in Word may not remain an equivalent field after conversion.

Start with the accessible Word source. In Word for Windows, choose File > Save As > PDF > Options and select Document structure tags for accessibility. On Mac, save as PDF and select Best for electronic distribution and accessibility. In Word for the web, use Download as PDF. Those tags help assistive technology interpret headings and reading order.

My approach is to build the accessible Word source first, run Word's Accessibility Checker, and only then convert to PDF if you need a fixed layout. The Word file stays your working source, not a disposable draft.

Conversion rule: Test the Word file and the exported PDF as separate products.

Open the PDF in the reader your recipient is likely to use. Check the visible layout, links, headings, reading order, field behaviour and keyboard navigation. Then test the saved file again after closing and reopening it.

If the final requirement is an interactive PDF, add actual PDF fields after export in a PDF-authoring application. Word controls alone shouldn't be assumed to become accessible PDF fields. This is also where PDF hyperlinks need a separate check, because conversion can affect how links behave even when the original document looked correct.

For a fixed document with no data-entry requirement, a tagged PDF may be enough. For a real PDF form, inspect the fields independently.

When to move beyond Word forms

Word is the right choice for a straightforward template with simple text fields and checkboxes, especially when recipients already work in Microsoft Office or need an offline document. It's familiar, printable and quick to revise.

It becomes the wrong choice when the form needs complex logic, strict validation, reliable behaviour across platforms or a central response workflow. If you're asking recipients to fill in a proposal, send it back, rename the file correctly and repeat that process for every revision, Word is carrying more operational weight than it should.

Requirement	Word is a sensible fit	Move to another platform
Field types	Simple text, dates and checkboxes	Complex controls or conditional paths
Distribution	A known recipient who can use Word	A broad audience on mixed devices
Response handling	Files returned individually	Central collection and structured records
Accessibility	A simple form you can test carefully	Complex interaction or demanding assistive technology needs
Communication	A document that stands alone	A proposal or contract needing explanation and follow-up

The decision changes again when the document is part of a sales conversation. A proposal can contain perfectly designed fields and still disappear in an inbox. Adding more controls won't tell you which pages the buyer read or whether they reopened it before your call.

That's the point at which a tracked PDF with a short video can make more sense than a bigger Word form. LiveDocument puts both behind one link, and page-level activity shows which pages got attention. It won't collect form responses, so it suits proposals and contracts you need to explain, not data capture. The question is whether your problem is building the document or communicating about it once it's sent.

Use Word when the recipient needs to complete a simple file. Move beyond it when the requirement is guided review, measured engagement or a reliable shared workflow. The guide to creating an interactive PDF can help you assess that next step.

If you're sending a proposal or sales document as a PDF or image, LiveDocument lets you attach a video walkthrough, share one link and see page-level views, with link expiration and revocation if you need to pull it back.