The Short Answer: Use htmlDefinition, Not documentBase64
To create a responsive HTML document through the DocuSign eSignature REST API, define the document in the documents array of your Envelopes:create request with an htmlDefinition object whose source property contains your page's HTML as plain text — not as a Base64 string. Set documentId to a string such as "1", set the document name, and set fileExtension to "html" (DocuSign's engineering blog also shows working examples with "htm"). Then POST the envelope to /restapi/v2.1/accounts/{accountId}/envelopes. Built this way, the document is routed through DocuSign's Responsive Signing system, and signers on phones and tablets get a web-style signing page that scales to their screen instead of a fixed-layout PDF.
The trap to avoid: passing HTML bytes through documentBase64. DocuSign's developer support team has documented that this routes the document through the normal processing pipeline and does not produce a responsive document; in some accounts it returns an error stating that HTML is not allowed for that call.
One availability caveat: advanced responsive signing — sending HTML directly and using Smart Sections — is available in all developer (sandbox) accounts but only in certain production plans, while basic responsive signing (automatic PDF-to-HTML conversion) is disabled by default and must be enabled by an account administrator. Confirm your production plan's capabilities with DocuSign support, and verify behavior in the sandbox first.
How Responsive Signing Fits Together
DocuSign documents two levels of responsive signing. In basic responsive signing, you supply a PDF (or another supported file type) and DocuSign converts it into a signable HTML document; existing tabs are preserved, anchor tabs stay attached to their text, and the result is stored as an envelope attachment you can retrieve. In advanced responsive signing, you send HTML directly and optionally add Smart Sections. Both produce pages that dynamically resize for a better mobile signing experience than a fixed PDF.
The htmlDefinition object also exposes mobile-specific controls from the API reference: maxScreenWidth, which limits the responsive HTML version to screens at or below a given pixel width (larger screens see the PDF version instead), and showMobileOptimizedToggle, which shows a Mobile-Friendly toggle on mobile devices so signers can switch to the PDF view before finishing.
The Envelope Request: htmlDefinition in Code
The official how-to guide for creating a signable HTML document uses three steps: obtain an OAuth token, build the envelope definition with an htmlDefinition node, and call the eSignature REST API. Here is the request in curl form with placeholder credentials.
```bash
curl -s -X POST "https://demo.docusign.net/restapi/v2.1/accounts/{$ACCOUNT_ID}/envelopes" \
-H "Authorization: Bearer {$JWT}" \
-H "Content-Type: application/json" \
-d @envelope.json
```
The envelope.json body below carries the HTML as text, maps a signer role for tab assignment, and includes one Smart Section definition:
```json
{
"emailSubject": "Your mobile-friendly agreement",
"status": "sent",
"documents": [
{
"documentId": "1",
"name": "agreement.html",
"fileExtension": "html",
"htmlDefinition": {
"source": "
Service Agreement
Terms text here
pricing_table_start
| Plan A |
pricing_table_end
","displayAnchors": [
{
"startAnchor": "pricing_table_start",
"endAnchor": "pricing_table_end",
"removeStartAnchor": true,
"removeEndAnchor": true,
"caseSensitive": true,
"displaySettings": {
"display": "responsive_table_single_column",
"tableStyle": "width:100%;max-width:816px;margin-left:auto;margin-right:auto;",
"cellStyle": "text-align:left;padding:0px;"
}
}
]
}
}
],
"recipients": {
"signers": [
{
"email": "signer@example.com",
"name": "Example Signer",
"recipientId": "1",
"roleName": "Signer"
}
]
}
}
```
Three details matter. First, documentId must be an integer between 1 and 2,147,483,647, encoded as a string without commas; tabs reference the document through it. Second, source is plain text — the how-to guide is explicit that you add your page's HTML directly to the value of source, not Base64. Third, watch your quoting: DocuSign's engineers recommend limiting quotation marks inside HTML definitions and using apostrophes instead, because extra double quotes inside JSON-embedded HTML frequently cause deserialization errors.
After the envelope is created, the signer receives an email with a signing link usable in the DocuSign mobile app or website. When the envelope completes, the signed documents and evidence live in the completed envelope — see the DocuSign certificate of completion and audit trail guide for what to retain. You can also read back stored definitions with GET /restapi/v2.1/accounts/{accountId}/envelopes/{envelopeId}/html_definitions (EnvelopeHtmlDefinitions:list).
Placing Tabs in an HTML Signing Document
Tabs in responsive HTML documents do not use xPosition/yPosition coordinates. DocuSign's "Setting tabs in HTML documents" guide describes two methods. The first is HTML blocks: each tab type has a corresponding DocuSign HTML tag, configured through attributes such as data-ds-role, data-ds-recipient-id, required, readonly, font-size, and color; attribute values override tab defaults. The second is JSON markers: embed markers containing a tabLabel in the HTML source, and each marker is replaced by the matching tab definition from your API request. Radio tabs are the special case — their markers must include groupName and value properties that map to a radio group.
Two constraints from the same guide will bite you if missed. Only inline styles are reflected in the processed document; styles defined outside the page, such as blocks or external CSS, are not applied. And when assigning tabs through the htmlDefinition, the tab's role must map to a recipient — set roleName on the signer (or use a server template or composite template) so inline tab definitions resolve to the right person.
After completion, extracting tab and form data from a signed document via the API is how your backend records what the signer entered.
Smart Sections for Mobile Optimization
Smart Sections are the mobile optimization layer inside htmlDefinition. Per the responsive signing concept guide, they support collapsible sections signers expand and collapse, rotating tables that convert multiple columns to a single column for narrow screens, and Continue buttons that create stop points before the signer proceeds. They work both on documents DocuSign converts from PDF and on HTML you send directly.
The JSON above shows the full shape: displayAnchors entries with startAnchor, endAnchor, removeStartAnchor, removeEndAnchor, and caseSensitive, plus a displaySettings object whose display value (here responsive_table_single_column, the rotating-table mode) selects the behavior, with tableStyle and cellStyle providing inline CSS. A start anchor, an end anchor, or both are required; if the anchor strings are not found in the HTML, the display anchor is ignored — so anchors must be literal, unique strings that survive your template rendering. The API reference also documents headerLabel, displayOrder, displayPageNumber, and displayAnchorPrefix (at least 4 characters improves anchor processing performance).
Limits and Gotchas to Verify in Your Sandbox
Run each item below in the developer sandbox and confirm plan-dependent behavior with DocuSign support before production.
- Account enablement. Basic responsive signing is disabled by default; advanced options are in all developer accounts but only certain production plans. Do not assume production parity from a sandbox success.
- Images must be embedded. When sending HTML directly, you cannot use image file links; images must be Base64-encoded inside
tags as data URIs, or they will not display. - Inline styles only. External stylesheets and
blocks are not applied; move styling into inline attributes on each element. - Restricted HTML and CSS. Responsive Signing disallows a number of HTML elements, attributes, and CSS properties for security reasons. Check the allowed-elements list in DocuSign's guide before committing to a design system.
- RTL is not supported. Right-to-left languages such as Hebrew, Arabic, and Farsi are not currently supported in Responsive Signing.
- JSON quoting. Extra double quotes inside HTML embedded in JSON cause deserialization errors; use apostrophes inside HTML definitions.
- Preview before send. The Preview option in eSignature Admin shows how content will appear to mobile signers in the responsive experience.
- Volume economics. If these envelopes are generated at product volume, plan capacity around DocuSign API rate limits and pricing tiers rather than single-envelope tests.
Mobile-First Signing, Simpler Terms: Nota Sign
Responsive HTML fixes how a document renders on a phone. Whether the platform behind it fits your product — plan-gated features, seat-based pricing built for sales teams rather than APIs sending at volume — is a separate decision.
Nota Sign is FaDaDa's e-signature platform for global business, and three of its strengths map directly onto a mobile-signing build:
- Completion anywhere — legal coverage in 100+ countries and regions, behind FaDaDa's #1 ranking in IDC's China e-signature software market for consecutive years, so a signer on a phone in any market signs with full legal weight.
- APAC identity built in — iAM Smart, Singpass, and SES/AES/QES assurance levels, plus regional data centers; our China eSignature REST API guide covers local integration patterns.
- Pricing that fits API products — no per-seat fees keeps small teams viable; mid-market and enterprise buyers work from tailored plans.
For the wider evaluation, see when comparing DocuSign alternatives makes sense, then start a conversation with the Nota Sign team.








