A submit button is the final piece of a functional PDF Forms workflow. After a user fills in text fields, selects dropdown options, and checks the appropriate boxes, the submit button packages all that form data and sends it to a destination where someone can act on it. Without a submit button, the user must save the filled PDF and manually email it as an attachment. With a properly configured submit button, the form data arrives as structured text in an inbox or database, ready for processing without any manual steps from the user.
Adding a submit button involves two separate tasks: placing the button control on the PDF page and configuring its action to send data to the correct destination. The action configuration determines where the data goes, what format it uses, and whether the user sees a confirmation message after submitting. Getting the action right is what separates a button that just sits there looking clickable from a button that reliably delivers form responses.
WukongPDF's Fillable PDF editor includes submit button controls that you can configure with a mailto address or a server endpoint. After configuring the button, test the full submission workflow before sending the form to recipients to confirm that data arrives intact.
How PDF Submit Buttons Work
In most cases, a PDF submit button is a form field of type button with an associated Submit Form action. When the user clicks the button, the PDF reader collects the current values of all form fields, serializes them into the chosen data format, and sends them to the specified destination. The destination can be an email address using the mailto: protocol, which opens the user's email client with the form data in the message body or as an attachment. Or it can be a web server URL using HTTP or HTTPS, which sends the data as a POST request that a server-side script receives and processes.
The data format options include FDF, the Forms Data Format used by Adobe products since the 1990s. XFDF, the XML-based version of FDF that is easier for non-Adobe systems to parse. HTML, which formats the field data as key-value pairs in an HTML document body. And PDF, which sends the entire filled PDF file as an attachment. The format choice depends on what system receives the data. Email recipients generally prefer PDF or HTML. Server scripts processing form submissions into databases prefer XFDF or FDF for structured parsing.
Method 1: Configuring a mailto: Submit Button
In practice, the mailto approach is the simplest to set up because it requires no server infrastructure. The submit button opens the user's default email application, creates a new message addressed to the specified recipient, and populates the message body or attaches the filled PDF. In Adobe Acrobat Pro, open the PDF, go to Tools, then Prepare Form. Click the Button icon in the toolbar and draw a button onto the page. Type a label such as Submit or Send Form.
With the button selected, open the Properties dialog. Under the General tab, give the button a name like SubmitButton. Under the Options tab, set the Layout to Label only and enter the button text. Under the Actions tab, select Mouse Up from the trigger dropdown, then click Add. Choose Submit a Form from the action type list. In the Submit Form Selections dialog, enter mailto:you@example.com as the URL. Choose PDF as the export format so the recipient receives the complete filled PDF. Click OK, close the properties, and save the PDF.
Test the submit button by opening the PDF in Adobe Acrobat Reader, filling in a few fields, and clicking Submit. The Reader should open your default email application with a new message addressed to you and the filled PDF attached. If the email client does not open, check that your operating system has a default mail application configured. mailto links rely on the system mail handler, and on some machines, particularly in corporate environments with web-based email, the mailto handler may not be configured.
Method 2: Submitting Form Data to a Web Server
For forms distributed to the public or to large teams where email-based submission becomes unwieldy, HTTP POST submission to a server script provides a more scalable data collection pipeline. The setup requires a server endpoint that can accept and process incoming PDF form data. The endpoint URL goes into the Submit Form action's URL field instead of a mailto address. When the user clicks submit, the PDF reader sends an HTTP POST request with the form data in the body. The server script parses the data, stores it, and returns a response that the PDF reader can display as a confirmation page.
Setting up the server endpoint is the more complex part of this workflow because it involves web development outside the PDF. A basic PHP, Python, or Node.js script that accepts POST requests, parses FDF or XFDF data, and writes the field values to a CSV file or database is typically 30 to 50 lines of code. The PDF side of the configuration is identical to the mailto setup except the URL points to the server endpoint instead of a mailto address. Many form management services offer pre-built endpoints that accept PDF form submissions, removing the need to write and host custom server code.
Customizing the Submit Button Appearance and Behavior
The default button appearance, a gray rectangle with centered text, works but does not match most form designs. In the button's Properties dialog under the Appearance tab, set the border color, fill color, font, and font size to match the form's visual style. A submit button with a blue fill, white text, and rounded corners draws more attention and gets more clicks than a default gray rectangle. Under the Options tab, you can assign an icon to the button that appears alongside or instead of the label text.
Across most tools, the button's Actions tab supports multiple actions on different triggers. Beyond the Mouse Up submit action, you can add a Mouse Enter action that changes the button color to indicate hover, and a Mouse Exit action that restores the original color. These visual feedback cues make the form feel more responsive and professional. Keep the interactive effects subtle. A button that changes to a slightly darker shade on hover is helpful. A button that animates or changes dramatically is distracting.
Security and Privacy Considerations
Form data submitted through a mailto link passes through the user's email client and the email infrastructure of both the sender and recipient. The data is not encrypted in transit unless both email servers enforce TLS. For forms collecting sensitive information such as personal identification numbers, health data, or financial details, mailto submission does not provide adequate security. HTTP POST to a server endpoint using HTTPS encrypts the data in transit between the PDF reader and the server, which is the minimum acceptable security level for any form that collects personal data.
When designing documents, the PDF reader that the recipient uses also affects submission behavior. Adobe Acrobat Reader supports the full range of submit actions including mailto and HTTP POST. Browser-based PDF viewers embedded in Chrome, Edge, and Firefox have limited or no support for PDF form submission actions. A submit button that works perfectly in Acrobat Reader may do nothing when the same PDF is opened in a browser tab. For forms distributed to external recipients whose PDF reader you cannot control, include a note near the submit button instructing users to open the file in Adobe Acrobat Reader if the button does not work in their browser.
| Submit Method | How It Works | Best For |
|---|---|---|
| mailto: URL action | Opens user's default email client with pre-filled subject and body containing form data | Internal forms, small teams, simple data |
| HTTP POST to server script | Sends form data as FDF or XFDF to a web server endpoint for processing | Public forms, CRM integration, automation |
| JavaScript + email API service | Custom JS button calls a third-party email API directly from the PDF reader | Forms where mailto reliability is insufficient |
A properly configured submit button turns a fillable PDF from a standalone form into a data collection endpoint. The mailto method handles internal team forms with zero server setup. The HTTP POST method scales to public distribution and automated data processing. Testing the submission workflow end to end before distribution catches configuration errors that would otherwise silently lose every form response submitted by your users. A submit button that works reliably removes the last point of friction between the form-filler and the form-owner, closing the loop on the entire fillable PDF workflow.
Troubleshooting Submit Button Failures
When a submit button does nothing on click, the most common cause is that the PDF reader does not support the action type. Browser-based PDF viewers generally do not support mailto or HTTP POST submit actions. The fix is to instruct users to open the file in Adobe Acrobat Reader specifically. Another common cause is the mailto URL being malformed. The correct format is mailto:address@example.com without any spaces or additional parameters unless they are properly URL-encoded.
If the button works but the email arrives with no data, the likely cause is that the export format was set to FDF or XFDF and the recipient's email client does not know how to display those formats. Change the export format to PDF in the Submit Form action settings. The filled PDF arrives as an email attachment, and the recipient can open it directly to see all the entered data. For forms where the recipient needs to see data at a glance in the email body, choose HTML as the export format. The field values appear as labeled text in the email message body, though the formatting is plain and does not preserve the visual layout of the original form.