Skip to main content

Signing Form Web Component

The <docuseal-form> web component renders a fully functional signing form inside your application. Signers can view the document, fill in fields, draw signatures, and submit — all without leaving your page.

Quick start

Add the embed script and drop in the component:
That is all you need to render a working signing form. The sections below cover every available attribute and event.

Attributes

The <docuseal-form> component accepts 39 data-* attributes to control behavior, pre-fill data, and customize the UI.

QuickSign recipe (2-click signing)

Combine data-name on the embed with confirmation_modal mode on the submission for a 2-click signing experience: ESIGN consent → signature carousel → done. Step 1 — Create the submission (server-side):
Step 2 — Embed the signing form (client-side):
What the signer sees:
  1. ESIGN consent modal — “I Agree & Continue”
  2. Bottom-sheet carousel with 2 steps:
    • Signature — auto-generated in Dancing Script cursive from data-name, with REDRAW option
    • Initials — auto-generated from name initials (e.g. “JS”), with REDRAW option
  3. Each signature/initials value is applied to ALL fields of that type across all pages
  4. Pre-filled text fields render as read-only overlays on the document (visible but not editable)
  5. After submission, your page is redirected to the completed_redirect_url from step 1
data-name vs data-signature: Use data-name for the carousel UX (auto-generates cursive, signer can redraw). Use data-signature to directly pre-fill a specific signature image or text without the carousel. Both work — data-name gives the better interactive experience.
The carousel only triggers when ALL required non-signature fields have values. If required text fields are empty, the form falls back to field-by-field mode. Make sure to pre-fill all required fields via the values parameter.

Full HTML example

This example demonstrates every available attribute:

Events

The <docuseal-form> component emits DOM custom events that you can listen to with addEventListener. Every event provides a detail property on the event object with relevant data.

init

Fired when the web component is initialized and the iframe begins loading.
Event detail: { component }, the <docuseal-form> element.

load

Fired when the iframe has loaded and the form is ready to render.
Event detail: { iframe }, the iframe element.

loaded

Fired when the form content has fully rendered and is interactive.
Event detail:
submitter is the signer’s slug (the last part of the signing link).

completed

Fired when the signer successfully submits the form. The event is cancelable: when redirect_url is an http(s) URL, the component redirects your page to it after the event unless a listener calls event.preventDefault().
Event detail:
The event carries no document, field or submission data. Fetch those from the API, or use the submission.completed / form.completed webhooks.

declined

Fired when the signer declines to sign the document.
Event detail:

field-value

Fired each time the signer fills in or changes a field value.
Event detail:

spitshake:resize

Fired when the form content height changes. Used internally by the web component to auto-resize the iframe. If you use a direct iframe, listen for this event to sync the iframe height. Event detail:

React integration

Use the web component directly in React with a ref for event handling:
Remember to include the embed script in your HTML. In React, add it to your index.html or load it dynamically:

Vue integration

Pre-filling fields

Use data-values to pre-populate form fields. The JSON object maps field names (as defined in the template) to their values.
Use data-signature to pre-fill the signature field. Accepted formats: a base64-encoded image (data:image/png;base64,...), an HTTPS image URL, or plain text that renders as a typed signature.
Supported field types for pre-fill:
Signature, initials, image, file, and stamp fields cannot be pre-filled via data-values. These require the signer to provide them interactively.

Redirect after completion

The redirect is set on the server, not on the embed. Pass completed_redirect_url when you create the submission (for everyone) or on a signer (for that signer only). The template’s redirect_url is the fallback. See Redirect after signing for the full order.
The URL must be an absolute http(s) URL (otherwise 422 with "code": "invalid_redirect_url") and is used as given: SpitShake adds no query parameters. Put your own identifiers in it when you create the submission. When the signer submits, the signing page sends spitshake:completed with the redirect_url, and <docuseal-form> fires its completed event and then redirects your page to that URL. Call event.preventDefault() in a completed listener to handle it yourself:
The signing page also tries to move the top window to the URL about half a second after submitting, and the browser may allow it. To be sure the signer stays on your page, create the submission without a redirect URL.
data-completed-redirect-url on the component has no effect. A signer who opens the signing link again after finishing, or who still has the form open in another tab, gets an Already Completed page. When a redirect URL is set it shows a Continue link to it, opened in the top window. It does not redirect on its own, and the component’s completed event does not fire again. A stale tab’s save or submit is refused with 422 and {"error": "Already completed", "code": "already_completed"}, and the page reloads to show Already Completed.

postMessage events

When the signing form is embedded in an iframe (either via the web component or a raw <iframe>), the form communicates with the parent window via postMessage. Each message is { type: "spitshake:<event>", data }; the payload is in event.data.data. Listen for these events to react to signing lifecycle changes without polling.
Use spitshake:completed as the trigger for your front-end workflow. It fires before any redirect. With a raw <iframe>, the signing page’s own attempt to move your page may be blocked by the browser, so read redirect_url from the payload and navigate yourself. For backend work (marking the agreement as signed), rely on webhooks, which also fire when the signer uses the emailed link.