Website and Conversion Content

Form Copy Review

Assess form labels, instructions, required fields, help text, validation, consent, errors, review states, submission, and completion messaging.

Free editable Markdown · Content designers, UX teams, and conversion teams · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Form context

Form and user goal: [Enter]
Entry and completion states: [Describe]
Data purpose: [Enter]
Consequence or commitment: [Describe]
Required versus optional information: [List]
Privacy or consent owner: [Name/role]
Form version and environment: [Enter]

Field card

Duplicate for every field.

Persistent label: [Write]
Required status: [Required / Optional]
Reason collected: [Explain]
Help text: [Write or None]
Example format: [Enter]
Allowed values or limits: [Enter]
Error message: [Problem and correction]
Sensitive-data concern: [Enter or None]
Dependency on another field: [Describe]

Choice and action review

Option group question: [Write]
Choices and default: [List]
Required consent text: [Enter]
Optional consent text: [Enter]
Review-before-submit summary: [Enter]
Primary button: [Exact action]
Secondary action: [Cancel / Save / Back / Other]
Irreversible warning: [Enter or None]

State and QA checks

Test states: [Success / Network / Timeout / Duplicate / Session / Other]
Issue owner and recheck trigger: [Enter]

Labels remain visible and programmatically associated.
Required fields and formats are explained before errors.
Errors identify, explain, and support recovery.
Entered data is preserved safely after validation failure.
Optional choices are not disguised as required.
Confirmation states the result, timing, and next step.

How to use this template

Define the user's goal, business purpose, data need, consequence, and end state.
Review every label, requirement, instruction, example, option, and button in sequence.
Trigger validation, system failure, timeout, duplicate, review, and confirmation states.
Check privacy, consent, accessibility, data preservation, and support paths with owners.
Revise and retest the working form across devices and relevant assistive technology.

Establish the transaction and necessary information

Write what the user is trying to accomplish, what the organization will do with the submission, and what information is genuinely required. Remove fields kept only from habit or future speculation. Group related inputs in the order people can answer them and show requirements before submission. A visible persistent label should identify each field; placeholder text can demonstrate format but should not carry the only instruction. For unusual terms, explain why the information is needed and how to find it. Preserve a user's entered values when an error occurs whenever safe and technically possible.

Write validation for prevention and recovery

State acceptable formats, ranges, character limits, file types, and dependencies before input when readers need them. Validation should identify the specific field, explain what is wrong, and tell the user how to correct it without blame. Avoid “invalid value” when “Enter the six-digit code from your email” is possible. Ensure the same message appears near the field and in an accessible summary when appropriate, with focus managed correctly by the implementation. Distinguish examples from actual user data and never ask for passwords or security secrets in ordinary form text.

Make consent and completion unambiguous

Separate required agreement from optional marketing choices and use clear, specific language reviewed by qualified owners. Do not preselect an optional choice or hide material terms behind a vague button. Before a consequential submission, summarize what will happen, whether it is reversible, and what evidence the user can review. The button should name the action. After submission, confirm success, reference, next step, expected timing, and safe recovery if a message does not arrive. Test failures, duplicate submission, expired session, and slow network so copy never claims success before the system completes.

See the fields in context

Fictional example: event registration code

FieldDay and its registration system are invented and do not collect real information.

Weak label: “Code,” with no explanation.
Revised label: “Six-digit invitation code,” followed by where the fictional user finds it.
Error: “Enter all six numbers from your invitation email,” instead of “Invalid.”
Action: The button says “Reserve my place,” and the review state shows the imaginary date and fee.
Confirmation: It provides a fictional reference and explains that reservation is complete only after email verification.

Frequently asked questions

Are placeholders acceptable as labels?

No. They disappear during input and may not provide a reliable accessible name. Use persistent labels.

Should every optional field say “optional”?

Make the requirement model consistent and obvious. Often labeling optional fields is clearer when most fields are required.

Where should error messages appear?

Associate them with affected fields and provide an accessible summary when the form or task warrants it.

How should button text be written?

Name the action and commitment, such as “Create account” or “Send request,” rather than a vague “Submit.”