---
title: "JavaScript digitally sign PDF via DWS Processor API | Nutrient"
canonical_url: "https://www.nutrient.io/guides/web/signatures/digital-signatures/signature-lifecycle/sign-a-pdf-document-dws/"
md_url: "https://www.nutrient.io/guides/web/signatures/digital-signatures/signature-lifecycle/sign-a-pdf-document-dws.md"
last_updated: "2026-06-09T10:14:21.528Z"
description: "JavaScript digitally sign PDF via DWS Processor | Nutrient API documentation for Nutrient Web SDK with methods, properties, and code examples."
---

# Sign a PDF via DWS Processor API using JavaScript

In this section, you’ll sign using certificates managed by [Nutrient DWS Processor API](https://www.nutrient.io/api/).

## Approval and certification signatures

PDF documents mainly support two types of digital signatures: approval signatures, and certification signatures. Approval signatures are used to indicate that a signer agrees with or acknowledges the contents of a document. A single document can contain multiple approval signatures. Meanwhile, certification signatures restrict the kind of changes that can be applied to a document once it’s signed. A PDF document only allows one certification signature. Nutrient provides support for approval signatures. For certification signatures, contact [Support](https://support.nutrient.io/hc/en-us/requests/new).

The remainder of this guide covers signing a PDF with an approval signature.

## Signing documents via DWS Processor API with the Web SDK

When using Nutrient Web SDK in standalone mode, you’re responsible for handling cryptographic operations manually. This can be a complex and error-prone process, especially when working with digital signatures. To streamline this, Nutrient provides a convenient alternative: leveraging the signing capabilities of our processing API service, Nutrient DWS Processor API. By offloading the signing process to DWS Processor API, you’ll simplify your integration without compromising security or control.

This approach is ideal if you want effortless integration of digital signatures into your app. Security and privacy of your documents is guaranteed, as the documents themselves remain secure and private in your client’s session; only the document hash and signature properties are transmitted to the backend. This ensures your sensitive content is never exposed during the signing process, keeping it safe and compliant with data privacy regulations.

Key benefits of signing via DWS Processor API include:

- Effortless integration — [Subscribe](https://www.nutrient.io/api/pricing/) to DWS Processor API to leverage its [digital signatures capabilities](https://www.nutrient.io/api/signing-api/).

- Trusted eSignatures — DWS Processor API provides a legally binding certificate that allows for secure signatures that validate in Adobe and are enforceable under European Union (eIDAS), US, and Canadian law.

- Delegated signing — Rather than managing cryptographic keys and processes in the client environment, you can delegate these operations to DWS Processor API, allowing for a more streamlined and secure experience.

- Document privacy — Your document remains on the client-side throughout the process. Only the document hash and necessary signature metadata are shared with the backend for signing, ensuring end-to-end document privacy.

### How to sign a document using DWS Processor API

If you’d like to use Nutrient DWS Processor API to sign documents via the Web SDK, follow the steps outlined below.

#### 1. Subscribe to DWS Processor API

Create an account or sign in to your existing account on the [DWS Processor API website](https://dashboard.nutrient.io/sign_up/?product=processor) to obtain your [API key](https://dashboard.nutrient.io/api/api_keys/).

#### 2. Authorize clients with a backend signing service

Prepare an [authorization token](https://www.nutrient.io/guides/dws-processor/developer-guides/authentication.md) that will allow your client to interact with DWS Processor API for signing operations.

For example, this request will create a token that allows the client to perform a digital signatures operation from origin `example.com` that expires in 1 hour (3,600 seconds):

```sh

curl -X POST https://api.nutrient.io/tokens \
  -H 'Authorization: Bearer pdf_live_<rest_of_your_api_key>' \
  -H "Content-Type: application/json" \
  -d '{
    "allowedOperations": [
      "digital_signatures_api"
    ],
    "allowedOrigins": [
      "example.com"
    ],
    "expirationTime": 3600
  }'

```

You can retrieve the `accessToken` from the response:

```json

{
  "accessToken": "<created_access_token>",
  "id": "<access_token_id>"
}

```

#### 3. Pass the access token to the signing method

Pass the access token to the [`signDocument`](https://www.nutrient.io/api/web/classes/NutrientViewer.Instance.html#signdocument) method of Web SDK running in standalone mode:

```js

instance.signDocument(
  {
    signingData: {
      signatureType: NutrientViewer.SignatureType.CAdES,
      padesLevel: NutrientViewer.PAdESLevel.b_lt
    }
  },
  {
    jwt: "<access token>"
  }
);

```

#### 4. Configure trusted certificates for validation and LTV

In standalone mode, Web SDK also needs trusted root certificates when validating signatures or adding long-term validation (LTV) information. Fetch the DWS CA certificates from your backend, and return them from [`trustedCAsCallback`](https://www.nutrient.io/api/web/NutrientViewer.Configuration.html#trustedCAsCallback) when loading the viewer:

```js

const certificatesResponse = await fetch("/api/signatures/certificates");
const certificates = await certificatesResponse.json();

const instance = await NutrientViewer.load({...configuration,
  trustedCAsCallback: async () =>
    // Decode the base64-encoded PEM strings returned by DWS.
    certificates.ca_certificates.map((certificate) => atob(certificate))
});

```

In this example, `/api/signatures/certificates` is an endpoint you implement on your backend to proxy the DWS `GET /i/certificates` response; it isn’t provided by Web SDK.

DWS returns `ca_certificates`; if your backend proxy renames response fields, adjust the property names accordingly.

Use `trustedCAsCallback` for trust anchors. Don’t pass DWS CA certificates to `signingData.certificates` when signing with `{ jwt }`; Web SDK fetches the signing certificate chain from DWS during the signing flow.

#### 5. Signing process

Once the signing method is called, the Web SDK takes care of the entire signing process:

1. Web SDK retrieves the signing certificate chain from DWS.

2. Web SDK prepares the document locally for signing based on the parameters provided to `signDocument`. Preparation options such as `flatten`, `position`, `formFieldName`, `appearance`, and `placeholderSize` are applied in the browser before hashing.

3. Web SDK generates the data to be signed and the hash of the prepared document.

4. Web SDK sends only the prepared `dataToBeSigned`, `hash`, `signatureType`, `signingToken`, and PAdES level (sent as `cadesLevel` on the wire) to DWS. The original document and preparation-only options aren’t sent to `/sign_hash`.

5. DWS performs the cryptographic signing. If requested, it also returns timestamping and LTV-related signature data.

6. Finally, the signed signature parameters are returned to Web SDK, which embeds them into the prepared document locally.

This process keeps your documents secure, maintains full privacy, and eliminates the need for clients to manage private keys, reducing the risk of handling cryptographic material in the client environment.

Avoid `flatten: true` in the final `signDocument()` call if the document already contains signature fields or previous digital signatures that must remain intact. Flattening is applied before the final signature hash is generated, and it can remove annotations, signature form fields, and previous signatures. If you need a flattened final PDF, flatten the document before applying the final digital signature. If the final signature should be placed in an existing signature field, pass its fully qualified name via `formFieldName`; otherwise, Web SDK may create a new signature field.

For a complete runnable implementation, see the [DWS hash signing catalog example](https://github.com/PSPDFKit/pspdfkit-web-examples-catalog/blob/master/examples/62-digital-signatures-hash-api/index.js).
---

## Related pages

- [Add signature fields to PDFs using JavaScript](/guides/web/signatures/digital-signatures/signature-lifecycle/add-a-signature-field.md)
- [Creating self-signed certificates for digital signatures](/guides/web/signatures/digital-signatures/signature-lifecycle/prepare-the-certificates-for-signing.md)
- [Configure digital signature appearance: Visible vs. non-visible Signatures](/guides/web/signatures/digital-signatures/signature-lifecycle/configure-digital-signature-appearance.md)
- [Sign a PDF via Document Engine using JavaScript](/guides/web/signatures/digital-signatures/signature-lifecycle/sign-a-pdf-document-document-engine.md)
- [Implementing a secure digital signature lifecycle](/guides/web/signatures/digital-signatures/signature-lifecycle/signature-lifecycle-overview.md)
- [Sign a PDF with a certificate in a browser](/guides/web/signatures/digital-signatures/signature-lifecycle/sign-a-pdf-document.md)
- [Validating a digital signature using JavaScript](/guides/web/signatures/digital-signatures/signature-lifecycle/validation.md)