HTML vs PDF Execution

What it is

Quik! offers two ways to generate a form: as an interactive HTML page (execute/html) or as a finished PDF document (execute/pdf). They share the same prefill logic, the same field naming, the same Form IDs, and the same UNID concept. What differs is what you get back and what you can do with it.

This page helps you pick the right one for your use case.

Why it matters

The choice between HTML and PDF determines the experience your users have:

• HTML is for when your users will sit in front of a form and fill it out interactively. They click into fields, the Save button works, Field Rules fire as they type, the Sign button triggers the e-signature popup. This is the most common use case for Quik!.
• PDF is for when you need a finished document without a UI step. You already have the data, you want a fully populated PDF you can archive, attach to an email, or upload to an e-signature vendor that requires a PDF (SIGNiX, custom integrations).

Picking the wrong one creates friction. HTML for a back-office archive workflow means an unnecessary browser step. PDF for end-user form-filling means no way to validate input or save progress.

How it works

What each method returns

Method	What you get back	Best for
execute/html	An interactive Quik! Form Viewer (either hosted by Quik! or HTML markup for you to host) plus a UNID.	Users filling out forms on screen.
execute/pdf	A PDF document (as a byte array or written to disk) plus a UNID.	Programmatic PDF generation, archiving, direct-to-PDF e-signature workflows.

Both methods support the same prefill mechanisms (FormFields, AddFieldToForm, LoadXML), the same role prefixes, and the same Form Group Instance behavior.

Key behavioral differences

Capability	HTML	PDF
User can fill out fields interactively	Yes	Only if PrintEditablePDF is true
Save button (save in progress)	Yes	No
Field Rules fire at runtime	Yes	No (rules applied to source data only)
Sign button and e-signature popup	Yes	No (e-sign happens outside the PDF)
Submit button events	Yes	No
Form Viewer customization (logo, styles, buttons)	Yes	No
Returned as a UNID-tied package you can re-launch	Yes	Yes

Decision: when to use which

If you need...	Use
End users to fill out a form in a browser	execute/html
A user to save a form mid-completion and resume later	execute/html
To send a form for e-signature through the standard DocuSign popup workflow	execute/html
A finished, prefilled PDF for archiving or attachment	execute/pdf
To upload a signable PDF to SIGNiX or a custom e-sign integration	execute/pdf with ForSign: true and PrintEditablePDF: false
A PDF that users can still edit after generation	execute/pdf with PrintEditablePDF: true
To generate forms in batch without any UI	execute/pdf

Mixed workflows are common

Most customer integrations use both endpoints at different stages:

• execute/html to render the form for the user, who fills it out and signs.
• execute/pdf (or the Submit/Print button events) later to produce a final archive copy.

You do not have to commit to one endpoint for your entire integration. Pick the one that fits each stage.

For developers: where this shows up in the API

This section is for the technical reader implementing the integration.

• execute/html endpoint at https://websvcs.quikforms.com/rest/QuikFormsEngine/qfe/execute/html. Returns a form viewer URL (when HostFormOnQuik is true) or HTML markup (when false). Also returns a UNID.
• execute/pdf endpoint at the same base path with /execute/pdf. Returns a PDF object with the byte array, the UNID (as FileName), and metadata.
• Shared request properties: QuikFormID, FormFields, LoadXML, ESignType, UNID (for re-launching).
• HTML-only properties: HostFormOnQuik, HTMLButtonSave, HTMLButtonSubmit, Form Viewer styling and customization properties. See the Hosted vs Self-Hosted Forms concept page for HostFormOnQuik tradeoffs.
• PDF-only properties: PrintEditablePDF (locks fields when false), ForSign (used with PrintEditablePDF: false to produce a signable PDF), OutputPath and OutputFileName (when writing to disk).
• PrintedPDF response object from execute/pdf includes:
  • PDF (byte array)
  • FileName (the UNID)
  • FormShortName (first form name in the bundle)
  • DealerName (first dealer in the bundle)
  • ID (auto-increment, always 1 for a bundle)

Pitfalls

• PDFs do not run Field Rules at runtime. Required-field validation, conditional logic, and other Field Rules only execute in the HTML viewer. If you generate a PDF directly, validation is your responsibility before calling the endpoint.
• PDFs do not support the Save button. A user filling out a non-flattened editable PDF (PrintEditablePDF: true) cannot use the Quik! save-and-resume flow. If you need save and resume, use HTML.
• PrintEditablePDF defaults differ by use case. Set it to false when producing a signable PDF for e-sign vendors that require flattened content. Set it to true only when end users will continue to edit the PDF after Quik! returns it.
• Once a PDF is generated, the form data is flattened to text by default. That is not reversible from the PDF. If you need to keep the data structured, save it on your side at the point of generation or use HTML with the Save button.
• execute/pdf does not give you an interactive viewer, even if PrintEditablePDF is true. The PDF is editable in a PDF viewer that supports form fields (Adobe Acrobat, etc.), but you do not get the Quik! Form Viewer UI features. For interactive UI, use HTML.
• E-signature workflow differs by endpoint. With HTML, the user clicks the Sign button in the viewer and Quik! handles the rest. With PDF, the e-sign step is outside Quik!: you upload the signable PDF to your vendor or use the Direct to DocuSign model. Match the endpoint to your e-sign vendor's expectations.

Related articles

Continue with these articles to understand the related concepts and workflows:

• Launch a Form — See how HTML and PDF execution fit into the form launch workflow.

• Saving Forms — Learn when saving applies to interactive forms and returned sessions.

• Send Direct to DocuSign — Understand how generated forms move into a DocuSign signing workflow.

• Sessions and UNIDs — Review how Quik! identifies and manages a user's form session.