Embedded eSignature: Iframes vs Native Components

If you are evaluating eSignature providers for a software platform, you have probably noticed that every vendor claims to support embedded signing, and that the claim tells you almost nothing.

This post is an attempt to make the comparison precise. Every statement about DocuSign below comes from DocuSign's own public documentation, OpenAPI specification, or official code examples, and is linked. We are a competitor, so treat our framing with appropriate skepticism, but the underlying facts are checkable and we would rather you checked them.

The short version: DocuSign's embedded envelope surfaces are their application, displayed inside a frame in yours. Verdocs ships UI components that render in your own DOM. Nearly every practical difference follows from that one architectural fact.

One clarification before we start, because it is the kind of thing a competitor usually omits. DocuSign's Click product (clickwrap agreement acceptance, not envelope signing) does ship a JavaScript component that renders into a selector in your own DOM, with a genuine per-element styling surface covering seven targets and their hover, focus, and disabled states. It is a well-built piece of software and it is not an iframe. Everything below concerns the eSignature envelope lifecycle: preparing, sending, signing, and managing documents. In that surface, the architecture is different.

First, what DocuSign genuinely offers

It is worth being complete about this, because comparison content in this category is usually written by people who have not read the API.

DocuSign's eSignature API exposes a set of endpoints that return short-lived URLs for embedded interfaces:

View	Endpoint	URL lifetime
Recipient (embedded signing)	`POST /envelopes/{id}/views/recipient`	5 minutes, single use
Sender (prepare and tag)	`POST /envelopes/{id}/views/sender`	10 minutes
Correct	`POST /envelopes/{id}/views/correct`	10 minutes
Template edit	`POST /templates/{id}/views/edit`	10 minutes
Shared recipient	`POST /envelopes/{id}/views/shared`	not documented
Envelope recipient preview	`POST /envelopes/{id}/views/recipient_preview`	not documented
Template recipient preview	`POST /templates/{id}/views/recipient_preview`	not documented
Console	`POST /views/console`	not documented

(The deprecated views/edit endpoint and the niche identity manual review view are omitted; DocuSign's documentation notes the former has been replaced by the Sender view.)

Embedded signing is mature, widely deployed, and used by Salesforce, Microsoft, SAP, and nCino, among others. Embedded sending and embedded template editing both work. DocuSign also has an ISV Embed partner program specifically for this use case.

Beyond the embedded views, several parts of their API are genuinely excellent and we will happily say so:

The Tabs API is complete. You can place fields by absolute coordinates (xPosition, yPosition, pageNumber) or by anchor string with offsets, at both envelope and template level, per document and per recipient. If you want to build your own document preparation interface, the primitives are all there.
Page images are available via GET /envelopes/{id}/documents/{docId}/pages/{n}/page_image, which gives you a rendering substrate for a custom tagging canvas.
responsive_html_preview returns responsive HTML of a document, which you can render and style however you like. It is the one DocuSign preview primitive with no styling constraints.
Search and audit APIs are rich. Envelopes::listStatusChanges supports free-text search, custom field search, date ranges, and a dozen sort orders. GET /envelopes/{id}/audit_events gives you full audit history.

None of that is in dispute. The question is what happens when you want a user interface.

The iframe boundary

Every embedded view in the table above returns a URL that you load in an iframe. Within the eSignature envelope surface, there is no case where you receive a component that renders in your own document.

This is not a criticism of the implementation; it is a deliberate architectural choice with real advantages. DocuSign controls the signing experience end to end, which means they can guarantee its compliance behavior, patch it globally, and keep the legal characteristics of the ceremony consistent across every integration. If you are integrating signing into an internal tool, that is a feature.

It has consequences, though, and they are worth stating concretely. Your CSS does not cross the frame boundary. Your design system does not apply. You cannot change the layout, restructure the flow, add your own affordances, or instrument what happens inside. On mobile, DocuSign advises against iframes for embedded operations and recommends a WebView on Android and WKWebView on iOS; for the recipient view specifically, they recommend Focused View if you do use an iframe. The signing URL expires in five minutes and can be used once, so you generate it at the moment of use rather than storing it.

Focused View is a wrapper around the frame, not a replacement for it

DocuSign's Focused View is often read as the answer to this, so it deserves specific attention. It is a real improvement over a raw iframe, and it is what we would recommend to anyone building on DocuSign today. It is not, however, a native component.

Here is the integration, from DocuSign's own Node code example:

<script src="https://js.docusign.com/bundle.js"></script>
<script>
window.DocuSign.loadDocuSign('<integrationKey>').then((docusign) => {
  const signing = docusign.signing({
    url: '<recipientViewUrl>',
    displayFormat: 'focused',
    style: {
      branding: {
        primaryButton: { backgroundColor: '#333', color: '#fff' }
      },
      signingNavigationButton: {
        finishText: 'You have finished the document! Hooray!',
        position: 'bottom-center'
      }
    }
  });
  signing.on('ready', handler);
  signing.on('sessionEnd', handler);
  signing.mount('#agreement');
});
</script>

Two details from DocuSign's own API specification establish that this is still a frame. The request requires frameAncestors to include DocuSign's own application domain: their spec says that in production you "include your site URL and https://apps.docusign.com." It also requires messageOrigins, where "the value must be https://apps.docusign.com," because the SDK communicates with the frame via postMessage. DocuSign's sibling Web Forms integration, which loads the same bundle.js, carries an iframeStyles option that a comment in their own example describes as styles that "get passed directly to the iframe that is rendered."

As for what you can restyle: across all five of DocuSign's official language example repositories, as of their July 2026 commits, the style object exposes four properties (primary button background color, primary button text color, finish button text, and finish button position) under DocuSign's own comment, "High-level components we allow specific overrides for." We could find no others documented. Fonts, layout, field chrome, the document viewer, dialogs, secondary buttons, and the header and footer are not among them.

A few practical notes for anyone building on it. The SDK is CDN-only; searching the npm registry for a corresponding package or TypeScript types returns nothing. The displayFormat property carries an empty description in DocuSign's OpenAPI specification, so the 'focused' value is discoverable only from code samples. In our own testing, your CSP must also permit frame-src for DocuSign domains alongside script-src and connect-src, and your returnUrl endpoint must not send X-Frame-Options, or the completion redirect is blocked inside the frame. Those last two are our findings rather than documented requirements.

Account branding has a defined ceiling

Beyond Focused View, DocuSign's branding is configured at the account level. The Brands API describes the color surface directly: an array of name-value pairs for "Button background, Button text, Header background, Header text."

Four color slots. Three logo slots (primary, secondary, email). Text customization happens by downloading XML resource files, editing individual strings, and uploading them again. Branding also requires the canSelfBrandSign or canSelfBrandSend account settings to be enabled.

This is a coherent system for a company branding its own signing. It is a narrow one for a platform trying to make signing look like a native feature of its product.

What Verdocs does differently

Our Web SDK ships the document lifecycle as standards-based custom elements, built with StencilJS. The SDK ships 75+ components. Six of them are complete experiences:

Component	Purpose
`<verdocs-build>`	Template building, including field placement
`<verdocs-send>`	Send a template to recipients
`<verdocs-sign>`	The signing experience
`<verdocs-preview>`	Read-only template preview with fields overlaid
`<verdocs-view>`	Read-only document viewing
`<verdocs-auth>`	Authentication, optionally headless

Beneath those sit the pieces you compose yourself: a drag-and-drop field editor (verdocs-template-fields), field property panels, role and workflow editors, envelope and template lists, eleven field type components, and a set of dialogs covering KBA, OTP, passcode, delegation, disclosure, and signature adoption.

Integration looks like ordinary front-end code:

import { VerdocsSign } from '@verdocs/web-sdk-react';

<VerdocsSign
  envelopeId={envelopeId}
  roleName={roleName}
  inviteCode={inviteCode}
  onSigningComplete={handleComplete}
/>

There are React and Vue wrapper packages on npm. Because the components are standards-based custom elements, they can also be used directly in Angular or with no framework at all.

The components render in your DOM

This is the load-bearing difference. Verdocs components do not use shadow DOM. They render into your application's light DOM, which means your stylesheets reach every element in them.

Our documented approach to theming is deliberately unsophisticated: inspect the element, write CSS.

#verdocs-view-header {
  background-color: #1b7591 !important;
}

We chose plain CSS overrides rather than a curated variable API on the reasoning that with that many components carrying dozens of styles each, most teams want to change a handful of specific things and should not have to learn a variable vocabulary to do it.

If CSS is not enough, the escape hatch is total. The SDK is MIT licensed with the full TypeScript source public on GitHub. You can fork any component and change its behavior, not just its appearance. That is a materially different ceiling from four style properties.

We also offer iframe embeds at app.verdocs.com/embeds/... for environments where custom elements are impractical, such as strict CSP contexts or legacy CMS platforms. Our documentation is blunt about the tradeoff: with iframes "you will have no styling/customization options." We mention it because pretending the iframe path does not exist would be the same overclaiming this post is arguing against.

Multi-tenancy: what is the token scoped to?

For a platform serving many downstream customers, this is the question that determines whether an embedded component is usable at all.

DocuSign's only embeddable view of envelope state is the Console view, and DocuSign's documentation carries an explicit information security notice about it: "This method provides full access to the sending account."

That is unambiguous, and it is the correct warning. It also means the Console view cannot be shown to a downstream tenant in a multi-tenant platform. If you want per-envelope status, detail, or audit history in your product, you build that interface yourself from GET /envelopes/{id} and GET /envelopes/{id}/audit_events. The data is all available; the UI is your project.

Verdocs issues two session types. A user session behaves conventionally. A signing session produces a token whose claims include envelope_id and role_name, scoped to one document and one participant. That is what makes it safe to hand to a browser in a multi-tenant application, and it is why our signing components can be mounted client-side without exposing anything beyond the single transaction in front of the user.

For platforms reselling signing, we model your customers as child organizations under your parent organization, and expose usage per organization so you can reconcile consumption against what you bill your own tenants. Twenty-three webhook events cover the envelope, template, and recipient lifecycle, authenticated by HMAC signature or OAuth2 client credentials.

The comparison, stated properly

The honest version of a competitive table for this category is not a grid of yes and no. Both platforms can do nearly everything. What differs is the delivery mechanism, so that is what the table should show.

Capability	DocuSign	Verdocs
Template / document builder	Embedded iframe (Template Edit view)	Native component (`verdocs-build`)
Template preview	Embedded iframe (Recipient Preview)	Native component (`verdocs-preview`)
Initiate document workflow	Embedded iframe (Sender view)	Native component (`verdocs-send`)
Document signing	Embedded iframe, or Focused View wrapper	Native component (`verdocs-sign`)
Document detail / status	Console iframe, account-scoped; otherwise build from API	Native components, envelope-scoped
Template / document search	API only	Native components (`verdocs-search-box`, list components)
Styling surface	4 style properties, 4 brand colors, 3 logos	Full CSS, or fork the MIT-licensed source
Component source	Not available	Public TypeScript on GitHub

Rows describe the eSignature envelope lifecycle. As noted at the top, DocuSign's Click product takes a different and more composable approach to clickwrap acceptance.

On search specifically: we checked every path in every OpenAPI specification DocuSign publishes. There is no embeddable search interface. Search is API-only, which is a perfectly reasonable design decision, but it means the interface is yours to build.

When you should choose DocuSign

We would rather say this plainly than have you discover we omitted it.

Choose DocuSign if your customers have named them specifically and their legal teams have already approved them, because that shortens your sales cycle in a way no architecture argument overcomes. Choose them if you need extremely broad international compliance coverage, including qualified electronic signatures under eIDAS. Choose them if your signing volume is low enough that the integration cost dominates every other consideration. Choose them if signing is peripheral to your product rather than on its critical path, and a frame is not a problem worth solving.

And if you are building on DocuSign today, use Focused View rather than a bare iframe. It is a real improvement.

When you should look at us

If signing is on the critical path of your product's core workflow, if your users should never perceive a handoff to another vendor, if you need to meter and bill signing to your own downstream tenants, or if you have ever been told by a vendor that the thing you want to change is not configurable, then the architecture described here is the reason we exist.

We are happy to put our SDK next to theirs with your engineering team and go through it honestly, including the cases where their answer is better.

Sources

All DocuSign claims above are drawn from these public sources:

EnvelopeViews: createRecipient (URL lifetime, single use, mobile WebView guidance, signer authentication responsibility)
EnvelopeViews: createSender (embedded sending, envelope state requirements)
EnvelopeViews: createConsole (the account access notice)
TemplateViews: createEdit (embedded template editing)
AccountBrands: create (brand color and logo surface, and the canSelfBrandSign / canSelfBrandSend prerequisite)
DocuSign Click (the clickwrap JS component and its styling surface)
DocuSign OpenAPI Specifications (endpoint enumeration across all published specs)
DocuSign Node code examples (the Focused View integration and its style surface)
DocuSign ISV Embed (embed partner program)

Verdocs technical claims:

This post reflects public documentation as of August 2026. DocuSign ships frequently, and we will correct anything that becomes outdated. If you believe we have characterized something unfairly, tell us and we will fix it.