XForms can make use of XML Schema datatype information, when available, as well as support rich validations expressed with declarative XPath.

Data submitted from XForms can be formatted as XML that conforms to any DTD or Schema, or simply well-formed. Legacy submission formats from classic HTML forms are also supported.

Initial form data can be specified from a separate XML document. Every form control has an identical interface to the form instance data. Thus, the results of one form can be easily directed into another form.

Designed from the ground up for accessibility, XForms supports and encourages form designers to follow best practices to achieve accessible design.

The combination of XML and Unicode enables consistent treatment of ASCII-excluded characters in form data or user interface. XForms have built-in conversion support for different representations of decimal numbers, dates, and times.

Different conformance profiles, called “XForms Full” and “XForms Basic” enable the deployment of forms across devices from powerful workstation computers to tiny phones and appliances.

Instead of script, declarative markup provides needed functionality. Scripting can still be used if needed, but often won’t be.

Form controls defined in XForms are similar to those defined in classic HTML forms, though better generalized and less specific to a particular hard-coded implementation choice:

Input, secret, and textarea all have similar counterparts in HTML. The XForms form controls, however, provide localization (for example, European users can enter “1,23” for a decimal number) and support for input modes, including eastern character sets and T9 predictive input on phone handsets.

Output is new in XForms, and provides a way to incorporate current information and summaries into form design.

Range is also new, providing smooth “volume control” selection from an ordered sequence.

Upload has a similar counterpart in HTML forms, but the XForms version accomplishes much more, and includes "device" upload, enabling microphones, scanners, cameras, and pen input.

Select and select1, finally, express the concepts of picking many or one items from a list. List selection items may be inline, as in HTML, or dynamic, based on instance data.

Form controls uniformly accept certain child elements that allow authors to provide additional information and functionality:

Beyond individual form controls, XForms also specifies:

<input ref="timecard/weekly/tue" inputMode="latin digits">
   <label>Hours Worked:</label>
   <hint>Enter a whole number of hours worked</hint>
</input>

A number of various XPath constraints and computations can be applied to the form data, using specific attributes on binding elements:

<model>
   ...
   <bind ref="timecard/weekly/*" required="1"/>
   <bind ref="timecard/total" calculate="sum(../weekly/*)"/>
   ...
</model>

In the course of form processing, often some particular action needs to happen. The XForms specification builds upon [XML Events], to trigger actions in response to various events. Individually, each XForms Action replaces only a small amount of script, but taken as a whole and in various combinations, about 80% of the most common scripting can be eliminated.

<input bind="searchParams">
   <label>Search Terms:</label>
   <send ev:event="DOMActivate" submission="sid"/>
</input>

The XForms specification uses and builds upon XPath, which includes adding some method calls useful for forms:

These can be called at any point where XPath is allowed. Additionally, implementations may support common "extension functions", including many from EXSLT [EXSLT], to provide additional functionality.

<bind ref="sales/commission"
   calculate="if( sales/total &gt; 100000, sales/total * 0.08, 0 )"/>

XForms Processing maintains the instance data in an internal XML structure. Upon submit, the XML is serialized into one of the following formats before sending over the wire: