DOMMatrix is not defined error when using Default Data Loader with PDF

Describe the problem/error/question

When using the Default Data Loader node to load a PDF binary file, the execution fails with the following error:

"errorMessage": "DOMMatrix is not defined",
"errorDescription": "DOMMatrix is not defined"

The following warnings are also logged in the container:

Warning: Cannot load "@napi-rs/canvas" package: "Error: Failed to load native binding".
Warning: Cannot polyfill `DOMMatrix`, rendering may be broken.
Warning: Cannot polyfill `ImageData`, rendering may be broken.
Warning: Cannot polyfill `Path2D`, rendering may be broken.

Steps to reproduce

  1. Set up a workflow with a PDF binary source (e.g. Google Drive, Webhook, Form node).
  2. Connect the binary output to a Default Data Loader node with Type of Data set to Binary.
  3. Execute the workflow.

Expected behavior

The Default Data Loader should successfully parse the PDF and pass the content downstream.

Actual behavior

The node fails with DOMMatrix is not defined. The @napi-rs/canvas package cannot be loaded, preventing pdfjs-dist from polyfilling the required browser-native APIs.

Information on my n8n setup

  • n8n version: 2.25.7 (Self Hosted)
  • Running n8n via: Docker
  • Binary data mode: filesystem

Additional context

This issue appears to have been introduced in v1.98.0 when pdfjs-dist was upgraded to a version that depends on browser-native APIs not available in Node.js server environments. It has been reported by multiple users in previous versions and seems to persist in v2.25.7.

What is the error message (if any)?

Please share your workflow

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

I think we have had a look at this exact thing today.

Try the latest beta version it fixed it for us.

While waiting on the beta test @menouaw there’s a reliable workaround that’s been confirmed across the related “DOMMatrix is not defined” threads: convert the PDF to text before the Default Data Loader using an Extract from File node (operation: “PDF”) earlier in the chain isn’t enough on its own since it hits the same pdfjs-dist/@napi-rs/canvas path.

Welcome @menouaw!

The fix in the latest beta is the right long-term path (BramKn’s suggestion). For an interim workaround while you’re on stable: use an HTTP Request node to call an external PDF-to-text API (like Docparser, Reducto, or any self-hosted Tika/Unstructured endpoint) instead of the Default Data Loader. That way your PDF text arrives as plain JSON without going through the pdfjs + @napi-rs/canvas path that’s causing the crash. Alternatively, if your Docker image is built on Alpine, the missing native bindings are usually fixed by switching to n8nio/n8n:latest (Debian-based) rather than the Alpine variant.