Introduction

In document-signing platforms, options such as Do Not Embed, Embed Sign, and Embed Without Signing describe how a user sees and interacts with a document inside your application. The differences are not just cosmetic. They affect who controls the user experience, whether the document can be signed, and where the user is sent to complete the workflow.

What Do Not Embed Means

Do Not Embed usually means the document flow is not shown inside your own page or application frame. Instead, the user is sent to a standalone hosted signing or viewing experience managed by the document platform.

This option is the easiest to implement because your application does not need to host an iframe or build an embedded session token. The tradeoff is reduced control over branding and navigation.

Typical uses include:

• sending a signer an email link to a hosted signing page
• redirecting a user to the provider's signing page
• using the provider's default authentication and completion screens

This mode is often best when speed matters more than UI integration.

What Embed Sign Means

Embed Sign means the signing experience is loaded inside your application, usually in an iframe or a web view, and the user can complete legally binding signature steps there.

The application usually requests a short-lived signing URL or token from the provider, then renders it in the page.

A simplified flow looks like this:

1async function openSigningSession() {
2  const response = await fetch("/api/signing-url", { method: "POST" });
3  const data = await response.json();
4
5  const frame = document.getElementById("signing-frame");
6  frame.src = data.signingUrl;
7}

1<iframe
2  id="signing-frame"
3  title="Document signing"
4  width="100%"
5  height="700">
6</iframe>

The backend might create the embedded session like this:

1app.post("/api/signing-url", async (req, res) => {
2  const signingUrl = await provider.createEmbeddedSigningUrl({
3    envelopeId: req.body.envelopeId,
4    signerId: req.body.signerId,
5    returnUrl: "https://app.example.com/signing-complete"
6  });
7
8  res.json({ signingUrl });
9});

The exact API differs by vendor, but the model is consistent: your app requests an embedded signing session, then hosts it.

What Embed Without Signing Means

Embed Without Signing usually means the document is shown inside your application, but the user is only reviewing, previewing, or filling non-signature information. The session is embedded, but signature actions are disabled or not part of the current step.

This is useful when:

• an internal user needs to preview the document before sending it
• a customer should read a document inside the app before choosing the next action
• a workflow separates review from final signing

Technically, the integration looks similar to embedded signing, but the permissions and session type are different. The platform may issue a viewer URL instead of a signer URL.

Choosing Between the Three

Use Do Not Embed when you want the provider to own the complete experience. It is simple and often the most robust starting point.

Use Embed Sign when the document must be signed without leaving your application. This is common in onboarding flows, checkout flows, and internal business systems where context switching is undesirable.

Use Embed Without Signing when the document should appear inside your app, but signing is either not allowed or not part of the current session.

The main question is whether the user must sign, and whether that action should happen inside your UI.

Security and UX Considerations

Embedded sessions often depend on short-lived URLs, recipient identifiers, and return URLs. That means your backend should generate the session just in time rather than storing a reusable link forever.

You should also design the host page carefully. If the iframe is too small or the surrounding page intercepts navigation badly, signing becomes unreliable. Embedded sessions work best when your page treats the document area as the primary focus.

Common Pitfalls

A common mistake is assuming embedding and signing are the same setting. They are related but separate. A document can be embedded for viewing without being signable.

Another issue is using an embedded signing URL for the wrong recipient or after the session has expired. These links are usually tied to a specific identity and session window.

Teams also sometimes choose embedded signing too early. If branding and in-app continuity do not matter, a hosted signing page is simpler and easier to support.

Finally, do not ignore return behavior. After completion or cancellation, the user needs a clear way back to your application workflow.

Summary

• 'Do Not Embed uses the provider's hosted experience outside your app.'
• 'Embed Sign shows a signable document inside your app.'
• 'Embed Without Signing shows the document inside your app without allowing signature actions.'
• Embedded flows usually require backend-generated session URLs or tokens.
• Choose based on signing needs, UI control, and operational complexity.