PDF.co vs PDFSharp: API vs .NET PDF Library

PDF.co vs PDFsharp: Managed PDF API or Self-Hosted .NET Library?

PDF.co and PDFsharp can both create and modify PDF documents, but they are designed for different development situations.

PDFsharp is an open-source .NET library that developers add directly to an application. It is best suited to teams that want to generate, draw, merge, split, or modify PDFs inside their own .NET environment while controlling the infrastructure and source code.

PDF.co is a managed REST API for document automation. It provides hosted endpoints for PDF conversion, OCR, data extraction, document parsing, barcode processing, PDF editing, and workflow integrations without requiring a team to build or maintain the underlying document-processing infrastructure.

The main decision is therefore not simply which product has more PDF features. It is whether your application needs an embedded .NET library or a hosted document-processing API.

Short Answer

Choose PDFsharp when:

  • Your application is built with .NET.
  • You want PDF functionality embedded directly in your application.
  • You need to create PDFs using programmatic drawing commands.
  • You want to merge, split, encrypt, sign, or modify PDFs locally.
  • Documents must remain within infrastructure you control.
  • Your team is prepared to maintain the PDF-processing code.
  • An MIT-licensed open-source library fits your deployment model.

Choose PDF.co when:

  • You need a REST API that works with any programming language.
  • You need OCR for scanned documents.
  • You need to convert PDFs to images, spreadsheets, text, JSON, XML, or HTML.
  • You need to generate PDFs from HTML, URLs, email, images, or documents.
  • You need invoice parsing, table extraction, barcode processing, or document classification.
  • You want asynchronous processing, callbacks, and managed infrastructure.
  • You are building workflows in Zapier, Make, n8n, Bubble, or another automation platform.

Use both when you want PDFsharp for fast local PDF generation or manipulation and PDF.co for specialized operations such as OCR, PDF-to-image conversion, structured extraction, or HTML-to-PDF rendering.

What Is PDFsharp?

PDFsharp is an open-source .NET library for creating and processing PDF files.

Developers install it as a package and call it from their application code. It provides drawing routines that will be familiar to developers who have worked with GDI+, Windows Forms, or WPF.

PDFsharp can be used to:

  • Create new PDF documents.
  • Draw text, lines, shapes, images, and other graphics.
  • Modify certain parts of existing PDFs.
  • Merge multiple PDF files.
  • Split PDFs into separate documents.
  • Add annotations and embedded files.
  • Apply encryption and password protection.
  • Embed and subset supported fonts.
  • Add CMS-based digital signatures.
  • Create reusable form XObjects.
  • Work with PDF document internals when lower-level control is required.

PDFsharp is written in C# and can be called from .NET languages. It is not a hosted service and does not provide a REST API by itself.

A team can wrap PDFsharp in its own web service, but that team is then responsible for the API design, hosting, scaling, monitoring, security, and ongoing maintenance.

What Is PDF.co?

PDF.co is a hosted document-processing API.

Applications send documents or source content to PDF.co through REST requests. PDF.co processes the job and returns the resulting file, extracted data, or job status.

PDF.co includes endpoints for:

  • Creating PDFs from HTML.
  • Creating PDFs from a public or authenticated URL.
  • Creating PDFs from images, documents, and email.
  • Converting PDFs to JPG, PNG, TIFF, and other image formats.
  • Converting PDFs to text, CSV, JSON, XML, Excel, and HTML.
  • Performing OCR on scanned PDFs and images.
  • Parsing invoices and other business documents.
  • Extracting tables and structured fields.
  • Merging and splitting PDFs.
  • Adding text, images, links, and form fields.
  • Reading and filling PDF forms.
  • Compressing PDFs.
  • Adding or removing passwords.
  • Rotating, reordering, and deleting pages.
  • Reading and generating barcodes.
  • Classifying documents.
  • Running asynchronous jobs with callbacks.

Because it is a REST API, PDF.co can be used from C#, Java, JavaScript, Python, PHP, Ruby, Go, Bubble, n8n, Zapier, Make, and other environments that can make an HTTP request.

The Main Difference: Embedded Library vs Managed API

PDFsharp becomes part of your .NET application.

Your code loads the document, runs the PDF operation, and writes the result. Processing occurs on the machine or server where your application is running.

PDF.co operates as an external API.

Your application submits a request to a managed service. PDF.co performs the operation and returns the result. The service handles much of the infrastructure required for document rendering, conversion, OCR, and extraction.

This distinction affects nearly every part of the implementation:

  • PDFsharp gives developers direct control over the PDF code and runtime.
  • PDF.co provides a broader collection of ready-to-use document endpoints.
  • PDFsharp requires .NET application development.
  • PDF.co can be called from almost any application or automation platform.
  • PDFsharp avoids per-document API charges but creates internal development and infrastructure costs.
  • PDF.co charges according to its usage model but reduces the amount of document-processing infrastructure a team must build.

PDFsharp Builds and Platform Support

PDFsharp 6.x is available in several builds. Choosing the correct build matters because graphics, font, and image behavior can differ.

PDFsharp Core

The Core build is intended for cross-platform applications. It can run on Windows, Linux, macOS, and other platforms supported by the applicable .NET runtime.

It is typically the right starting point for:

  • ASP.NET applications.
  • Linux-hosted services.
  • Containers.
  • Cross-platform command-line applications.
  • Serverless or cloud-hosted .NET applications.

The Core build does not rely on GDI+ or WPF. Developers may need to provide a custom font resolver, particularly when an application cannot rely on fonts installed on the host.

Its directly supported image formats are also more limited than those of the Windows-specific builds. According to the project documentation, JPEG, PNG, and Windows BMP are supported, while other image types may require conversion.

PDFsharp GDI+

The GDI+ build uses Windows graphics functionality and is intended for Windows applications.

It can be a good fit when an existing Windows application already relies on System.Drawing or related APIs. It generally provides broader access to Windows fonts and image formats than the Core build.

It is not the appropriate build for a Linux-hosted or fully cross-platform deployment.

PDFsharp WPF

The WPF build is also Windows-specific and uses Windows Presentation Foundation graphics classes.

It may be appropriate for desktop applications built around WPF or applications that need closer integration with WPF drawing objects.

Developers should review the current PDFsharp version and build guidance before selecting a package.

PDFsharp vs MigraDoc

PDFsharp and MigraDoc are related, but they solve different PDF-generation problems.

PDFsharp provides drawing commands. The developer decides where individual elements should appear on the page.

It is useful for:

  • Drawing at exact coordinates.
  • Adding text to predetermined positions.
  • Creating tickets, labels, certificates, or overlays.
  • Building custom page graphics.
  • Modifying existing PDF pages.
  • Creating a document where the developer controls the layout algorithm.

PDFsharp’s built-in text layout is basic. It does not automatically provide the full flowing-document behavior expected from a word processor.

MigraDoc is the related high-level document-generation library. It supports document concepts such as:

  • Paragraphs.
  • Sections.
  • Tables.
  • Headers and footers.
  • Charts.
  • Bookmarks.
  • Tables of contents.
  • Indexes.
  • Automatic text flow.
  • Automatic page breaks.

MigraDoc uses PDFsharp to produce PDF output. It can also produce RTF.

For reports, proposals, statements, and other documents where content needs to flow across pages, MigraDoc may be more appropriate than drawing everything directly with PDFsharp.

PDF.co takes a different approach. It can render an existing HTML template or webpage into a PDF, allowing teams to use HTML and CSS for document layout instead of defining every position in C#.

PDF Generation

Both products can create PDFs, but their preferred inputs are different.

Generating PDFs With PDFsharp

PDFsharp creates PDFs programmatically. A developer opens a document, adds pages, creates a graphics object, and draws the required content.

This approach provides precise control over:

  • Page size.
  • Coordinates.
  • Lines and shapes.
  • Font placement.
  • Image placement.
  • Colors and transparency.
  • Reusable graphics.
  • Headers, stamps, and overlays.

It works especially well when the PDF layout is highly controlled and the application is already written in .NET.

The development team must implement layout logic, overflow behavior, pagination, error handling, and document testing. MigraDoc can reduce some of that work for flowing documents.

Generating PDFs With PDF.co

PDF.co can generate PDFs from several existing content formats, including:

  • HTML strings.
  • URLs.
  • Images.
  • Office and other supported documents.
  • Email messages and attachments.

HTML-to-PDF is especially useful when a team already has web templates for invoices, receipts, reports, certificates, or account statements.

Developers can send HTML and CSS to the API instead of rebuilding the layout with PDF drawing primitives.

PDF.co is therefore often faster to implement when:

  • The source is already HTML.
  • The page contains CSS-based branding.
  • A webpage must be captured as a PDF.
  • A low-code workflow generates the document.
  • Several programming languages need to use the same PDF service.

HTML and URL to PDF

PDFsharp does not include a native browser engine or a built-in, out-of-the-box HTML-to-PDF converter.

A development team that wants to create PDFs from HTML must introduce another renderer, use a third-party library, or translate the content into PDFsharp or MigraDoc layout instructions.

This creates additional decisions around:

  • CSS support.
  • JavaScript execution.
  • Web fonts.
  • Page sizing.
  • Headers and footers.
  • Browser compatibility.
  • External images and stylesheets.
  • Authentication for protected pages.

PDF.co provides dedicated PDF generation endpoints for HTML and URLs. It is the more direct choice when the scenario is “turn this HTML, template, or webpage into a PDF.”

Editing Existing PDFs

PDFsharp can open existing PDF files and perform operations such as:

  • Importing pages.
  • Merging documents.
  • Splitting documents.
  • Drawing new content over an existing page.
  • Adding annotations.
  • Changing supported document properties.
  • Working with lower-level PDF objects.

However, editing existing page content is not the same as editing a Word document.

PDF content often consists of individually positioned drawing instructions. PDFsharp does not provide a full visual editing model that automatically identifies paragraphs, reflows text, and adjusts surrounding elements.

Low-level editing may require knowledge of PDF object structures, coordinate systems, fonts, content streams, and resource dictionaries.

PDF.co provides API endpoints for common editing tasks such as:

  • Adding text.
  • Adding images.
  • Adding links.
  • Adding form fields.
  • Searching for text.
  • Deleting or replacing selected text.
  • Rotating pages.
  • Deleting pages.
  • Applying passwords.
  • Adding a visible signature image.

PDF.co can reduce the amount of PDF-internals code required for standardized editing operations. PDFsharp may offer more flexibility when a .NET developer needs custom, local manipulation and is comfortable working closer to the PDF structure.

Text and Data Extraction

PDFsharp should not be treated as a complete high-level text-extraction system.

Its documentation notes that developers can access text-related content at a relatively low level, but characters may appear in drawing order rather than natural reading order. It does not automatically reconstruct words, paragraphs, columns, or tables.

This matters because a PDF may visually resemble a document while internally storing text as many separate positioned characters.

PDFsharp alone is therefore not the best fit when the requirement is:

  • Extract paragraphs in reading order.
  • Detect tables.
  • Return invoice fields.
  • Convert a PDF to structured JSON.
  • Convert tables to CSV or Excel.
  • Extract data from many document layouts.
  • Process scanned documents.

PDF.co provides endpoints for converting PDFs into:

  • Plain text.
  • Searchable text.
  • CSV.
  • JSON.
  • XML.
  • Excel.
  • HTML.

It also provides document parsing and invoice parsing features for structured business data.

The quality of any extraction depends on the source document. Digital PDFs with an embedded text layer are generally easier to process than scans, photographs, or documents with complex multi-column layouts.

OCR for Scanned Documents

PDFsharp does not include an OCR engine.

It can manipulate the PDF container and images, but it does not automatically recognize text inside scanned page images.

A team using PDFsharp for OCR must integrate and maintain a separate OCR library or service.

PDF.co includes OCR as part of its conversion and extraction workflows. This allows an application to:

  • Recognize text in scanned PDFs.
  • Process photographed documents.
  • Create searchable output.
  • Extract text before applying parsing rules.
  • Return structured data from documents without an existing text layer.

For scanned invoices, receipts, forms, statements, or archival documents, PDF.co covers more of the required processing pipeline without a separate OCR deployment.

PDF to JPG or PNG

PDF-to-image conversion is an important distinction between the products.

PDFsharp does not render PDF pages into images. Its own FAQ states that it cannot display, print, or create images from PDF files by itself. An external renderer, such as Ghostscript or another PDF-rendering library, is required.

This means a PDFsharp-based PDF-to-JPG service would need at least one additional rendering component. The team must also manage:

  • Installation and deployment.
  • Licensing of the selected renderer.
  • Resolution and image-quality settings.
  • Memory use.
  • Concurrency.
  • Font availability.
  • Problematic or malformed documents.
  • Security updates.

PDF.co provides a dedicated PDF-to-image API for converting pages to formats such as JPG and PNG.

It is the more direct choice for applications that need:

  • PDF thumbnails.
  • Page previews.
  • JPG or PNG versions of each page.
  • Images for OCR or computer-vision pipelines.
  • Website preview galleries.
  • Images for downstream storage or analysis.

PDFsharp may still be used before or after conversion—for example, to add a local overlay before sending the completed PDF to PDF.co for rendering.

Merging and Splitting PDFs

Both products support PDF merging and splitting.

PDFsharp can perform these operations locally inside a .NET application. This is attractive when:

  • The files are already available locally.
  • No specialized conversion is required.
  • The operation must remain within a private environment.
  • The team wants to avoid an external API call.
  • The application already depends on PDFsharp.

PDF.co provides hosted merge and split endpoints. This can be preferable when:

  • The workflow is built in a low-code platform.
  • Files arrive from cloud storage or URLs.
  • The application is not written in .NET.
  • The team wants a shared document API across multiple systems.
  • Job status and callbacks are useful.

For straightforward merging in an established .NET service, PDFsharp can be highly efficient. For integration-driven workflows, PDF.co may require less surrounding infrastructure.

Forms

PDFsharp provides access to PDF internals and some AcroForm functionality, but its high-level form support is limited.

Teams should test the exact form operations they require, especially for:

  • Reading field values.
  • Updating existing fields.
  • Adding new fields.
  • Flattening fields.
  • Working with appearance streams.
  • Handling calculation scripts.
  • Supporting XFA forms.
  • Preserving compatibility across PDF viewers.

PDF.co provides API operations for reading and filling PDF forms, as well as adding supported form fields through editing endpoints.

Neither product should be selected for a complex form workflow without testing representative documents. PDF forms vary significantly, and XFA-based forms are particularly different from standard AcroForms.

Digital Signatures

PDFsharp 6.2 added support for CMS-based cryptographic digital signatures.

Its default signer can use an X509Certificate2, and developers can implement a custom signer through the signing interface. Optional timestamping is also available in supported runtime configurations.

This makes PDFsharp useful when a .NET application needs to cryptographically sign a PDF and the team already manages:

  • Digital certificates.
  • Private-key security.
  • Certificate chains.
  • Timestamp authorities.
  • Signing policy.
  • Long-term validation requirements.

Cryptographic PDF signing is different from placing a visual image of a handwritten signature on a page.

PDF.co can add a signature image or other visible mark through its PDF editing functionality. That is useful for visual approval workflows, but it should not automatically be described as equivalent to a certificate-backed digital signature.

Neither PDFsharp nor a simple PDF editing endpoint should be confused with a complete electronic-signature platform that manages recipients, identity verification, consent, reminders, audit trails, and signing ceremonies.

Passwords and Encryption

PDFsharp supports PDF encryption and password protection, including modern encryption options documented by the project.

Because the operation happens locally, the development team controls:

  • Password handling.
  • Key and certificate storage.
  • Logging.
  • File retention.
  • Output storage.
  • Access to decrypted documents.

PDF.co also provides endpoints for adding and removing supported PDF password protection.

The better option depends on the surrounding system. PDFsharp may be preferable when sensitive documents must never leave controlled infrastructure. PDF.co may be preferable when encryption is one step in a broader hosted document workflow.

Teams should never place document passwords directly into insecure logs, source code, or workflow fields visible to unauthorized users.

PDF/A Archiving

PDFsharp’s PDF/A functionality should be evaluated carefully.

The project documentation describes its PDF/A work as under construction. It provides mechanisms for creating certain new PDF/A-oriented documents, but it does not offer a complete system for:

  • Converting any existing PDF into PDF/A.
  • Checking whether an existing document is PDF/A compliant.
  • Guaranteeing that imported pages or external objects remain compliant.
  • Replacing a dedicated PDF/A validation tool.

The PDFsharp documentation recommends validating archival documents with a tool such as veraPDF.

Do not assume that setting PDF/A-related metadata alone makes a document compliant. Fonts, color profiles, transparency, encryption, metadata, annotations, and embedded files can all affect conformity.

If PDF/A compliance is a contractual or regulatory requirement, test the exact output against the required PDF/A level using an independent validator.

PDF/UA and Accessibility

PDFsharp provides APIs and extensions that can help developers add accessibility structure to generated PDFs, including:

  • Structure information.
  • Reading order.
  • Alternative descriptions.
  • Artifact markers.
  • Semantic tags.

The presence of these APIs does not make every generated PDF accessible automatically. Developers must apply the appropriate structure and validate the resulting document.

HTML-to-PDF conversion also does not automatically guarantee PDF/UA compliance. Accessibility depends on the source markup, rendering process, semantic output, reading order, alternative text, form labeling, and other factors.

For either approach, teams with accessibility requirements should test output with the appropriate PDF accessibility tools and manual review procedures.

Fonts and Images

PDFsharp provides detailed control over fonts and images, but behavior depends on the selected build and hosting environment.

Important considerations include:

  • PDFsharp supports TrueType fonts and OpenType fonts with TrueType outlines.
  • Other font outline types may not be supported in the same way.
  • Server or cross-platform deployments may require a custom font resolver.
  • A font installed on a developer’s computer may not exist in production.
  • Core, GDI+, and WPF builds differ in how they locate and process fonts and images.
  • Some image formats may need conversion before use in the Core build.

These differences should be tested early, particularly for containerized Linux deployments.

With PDF.co, font and image behavior depends on the chosen endpoint and source format. For HTML-to-PDF, teams should make required web fonts explicitly available and avoid relying on local fonts that the rendering environment cannot access.

In both products, embedding the correct fonts is important for consistent output.

Compression and File Optimization

PDFsharp can apply compression to PDF streams, but teams should not assume it will dramatically reduce every PDF.

If a PDF already contains compressed JPEG images or efficiently encoded content, recompressing its internal streams may produce only a small reduction. Major size reductions often require image resampling, quality changes, removal of unused objects, or more specialized optimization.

PDF.co provides a PDF compression endpoint intended for common automated compression workflows.

Before choosing either approach, define what “compress” means for the use case:

  • Lossless structural compression.
  • Reduced image resolution.
  • Lower image quality.
  • Removal of metadata or unused content.
  • Web optimization.
  • A specific maximum file size.

Always test with representative documents. A method that works well for scanned image PDFs may have little effect on digitally generated text PDFs.

Integrations and Workflow Automation

It would be inaccurate to say that PDFsharp cannot be integrated.

PDFsharp can be integrated into any compatible .NET application. It is distributed through NuGet packages and can be used in:

  • ASP.NET services.
  • Desktop applications.
  • Background workers.
  • Azure Functions.
  • Containerized .NET services.
  • Internal business applications.
  • Custom command-line tools.

However, PDFsharp is not a ready-made integration service.

To use it from Bubble, Zapier, Make, n8n, Salesforce, or a non-.NET application, a team usually needs to build and host its own service around the library.

PDF.co provides a REST interface and is therefore easier to connect to:

  • Zapier.
  • Make.
  • n8n.
  • Bubble.
  • Pipedream.
  • Postman.
  • Power Automate through HTTP requests.
  • Custom applications in many languages.

For example, a Bubble workflow can upload a file and call a PDF.co endpoint through Bubble’s API Connector. A comparable PDFsharp implementation would normally require a separate .NET backend that Bubble calls.

Deployment and Data Privacy

PDFsharp processes documents in the environment where the application is deployed.

This can be an important advantage for:

  • Air-gapped systems.
  • On-premises applications.
  • Restricted document repositories.
  • Organizations with strict data-residency requirements.
  • Workflows that prohibit sending files to an external processor.

However, self-hosting also makes the team responsible for:

  • Server security.
  • Runtime updates.
  • Dependency updates.
  • File cleanup.
  • Temporary-storage security.
  • Malware and malformed-document handling.
  • Concurrency controls.
  • Logging and monitoring.
  • Backup and disaster recovery.
  • Incident response.

PDF.co is a hosted service, so documents are sent to an external processing environment. Organizations should review PDF.co’s current security, privacy, retention, regional, and contractual documentation before using it with regulated or confidential data.

The correct choice should follow the organization’s actual data-classification policy, not a general assumption that hosted or self-hosted processing is always preferable.

Scaling and Reliability

PDFsharp does not impose an API rate limit because it is a library. Its capacity depends on the application infrastructure.

A team can scale PDFsharp by:

  • Running more application instances.
  • Using background queues.
  • Assigning CPU and memory limits.
  • Isolating document-processing workers.
  • Adding retry and timeout handling.
  • Monitoring failed documents.
  • Controlling job concurrency.

This provides flexibility but requires engineering work.

PDF.co provides managed document-processing infrastructure and supports asynchronous processing and callbacks for longer jobs. That can reduce the operational work required to build a production document pipeline.

The team still needs to handle:

  • API authentication.
  • Retries.
  • Timeouts.
  • Usage limits.
  • Failed jobs.
  • Source-file availability.
  • Result-file storage.
  • Unexpected or malformed documents.

A managed API removes some infrastructure work, but it does not eliminate the need for robust workflow design.

Licensing and Pricing

PDFsharp is distributed under the MIT License.

According to the project’s license information:

  • Commercial use is allowed.
  • There are no library royalties.
  • Applications using PDFsharp do not have to become open source solely because they use the library.
  • The required copyright and permission notice must be included as specified by the license.

Organizations should have legal counsel review licensing requirements for their particular distribution model. This comparison is not legal advice.

PDF.co uses paid, credit-based plans.

At the time of this review, annual-billing prices displayed on the PDF.co pricing page included:

  • Basic: $8.99 per month with 16,500 credits.
  • Personal: $22.49 per month with 37,000 credits.
  • Business 1: $44.99 per month with 80,500 credits.
  • Business 2: $89.99 per month with 159,850 credits.
  • Business 3: $270 per month with 483,000 credits.
  • Enterprise: custom pricing.

Pricing, included credits, and credit consumption can change. Check the current pricing page and the credit cost of the specific endpoint before estimating production costs.

Total Cost of Ownership

PDFsharp is free to license, but the full implementation is not necessarily free.

Potential PDFsharp costs include:

  • .NET development.
  • Layout implementation.
  • Server or container infrastructure.
  • Monitoring.
  • Dependency maintenance.
  • Font management.
  • An external renderer for PDF-to-image.
  • An OCR engine.
  • An HTML rendering engine.
  • Document parser development.
  • Security review.
  • Support for unusual or malformed PDFs.

Potential PDF.co costs include:

  • Monthly or annual API fees.
  • Usage credits.
  • Network transfer.
  • Storage outside the API.
  • Integration development.
  • Retry and job-monitoring logic.
  • Increased usage as document volume grows.

For simple local merging or PDF generation in a .NET application, PDFsharp may have a lower total cost.

For OCR, rendering, structured extraction, or multi-platform automation, PDF.co may cost less than assembling and operating several separate libraries and services.

When PDFsharp Is the Better Choice

PDFsharp is likely the better fit when:

  • The application is already built in .NET.
  • PDF processing must occur locally.
  • The main tasks are creation, drawing, merging, splitting, or overlaying.
  • The team needs precise coordinate-level control.
  • The documents cannot be sent to an external service.
  • Developers want an MIT-licensed library.
  • The team can maintain the required document code and infrastructure.
  • Cryptographic signing with managed certificates is required.
  • PDF volume is high but operations are relatively simple.

Example:

A Windows or ASP.NET application generates thousands of branded certificates using known fonts, images, and fixed positions. No OCR, HTML rendering, or extraction is required. PDFsharp can generate the documents locally without an API request for every certificate.

When PDF.co Is the Better Choice

PDF.co is likely the better fit when:

  • The application is not limited to .NET.
  • The workflow needs HTML-to-PDF or URL-to-PDF conversion.
  • PDFs must be converted to JPG or PNG.
  • Scanned documents require OCR.
  • Tables or invoice fields must be extracted.
  • Output is needed in CSV, JSON, XML, Excel, or HTML.
  • The workflow is built with Bubble, Zapier, Make, or n8n.
  • The team does not want to deploy multiple document-processing engines.
  • Asynchronous jobs and callbacks are useful.
  • A shared REST API must support several applications.

Example:

Invoices arrive as email attachments and must be converted into structured data for an ERP. PDF.co can provide email handling, OCR, conversion, and extraction endpoints through one API. PDFsharp alone would require separate email, OCR, parsing, and integration components.

When to Use PDFsharp and PDF.co Together

The products can complement each other.

A hybrid workflow might:

  1. Generate or modify a PDF locally with PDFsharp.
  2. Send the completed PDF to PDF.co for OCR, conversion, or extraction.
  3. Store the returned result in the application’s database or document repository.

Other examples include:

  • Generate a report with MigraDoc, then convert its pages to JPG through PDF.co.
  • Merge confidential source files with PDFsharp, then send only an approved subset for external OCR.
  • Add custom graphics locally with PDFsharp, then extract searchable text with PDF.co.
  • Use PDF.co to convert HTML into PDF, then apply a certificate-backed digital signature with PDFsharp.
  • Use PDF.co to parse an invoice, then use PDFsharp to create a locally stored audit summary.

This approach allows a team to keep simple or sensitive operations local while using a managed API for functionality that would otherwise require additional engines.

Questions to Ask Before Choosing

Before selecting either approach, ask:

  • Is the application already built with .NET?
  • Must every document remain inside our infrastructure?
  • Do we need OCR?
  • Do we need PDF-to-JPG or PDF-to-PNG conversion?
  • Do we need HTML or webpage rendering?
  • Do we need high-level text or table extraction?
  • Do we need invoice or document parsing?
  • Are the source documents digitally generated or scanned?
  • Do we need a cryptographic signature or only a visible signature image?
  • Do we need PDF/A or PDF/UA validation?
  • Will the workflow be used from low-code tools?
  • Can our team maintain fonts and rendering dependencies across platforms?
  • What happens when a PDF is malformed?
  • What volume and concurrency must the system support?
  • Is predictable internal infrastructure cost more important than API convenience?
  • Have we tested representative production documents?

A proof of concept should include difficult real-world files, not only simple sample PDFs.

Frequently Asked Questions

Is PDFsharp free?

Yes. PDFsharp is available under the MIT License and can be used in commercial applications, subject to the license conditions.

Infrastructure, development, maintenance, and any additional rendering or OCR components still create costs.

Does PDFsharp work on Linux?

The PDFsharp Core build is designed for cross-platform .NET environments, including Linux.

Font resolution, images, and other graphics behavior should be tested in the actual deployment environment. The GDI+ and WPF builds are Windows-specific.

Can PDFsharp convert a PDF to JPG?

Not by itself.

PDFsharp does not render PDF pages into images. A separate PDF renderer is required. PDF.co provides a dedicated PDF-to-image API.

Can PDFsharp perform OCR?

No. PDFsharp does not include an OCR engine.

A separate OCR library or service is required. PDF.co provides OCR-enabled document-processing endpoints.

Can PDFsharp convert HTML to PDF?

PDFsharp does not provide a complete native HTML and CSS rendering engine.

Developers must use another renderer, a third-party integration, or translate the document into PDFsharp or MigraDoc instructions. PDF.co provides HTML-to-PDF and URL-to-PDF endpoints.

Can PDFsharp extract text from PDFs?

PDFsharp can expose lower-level PDF content, but it does not provide a complete high-level extraction system that automatically reconstructs words, paragraphs, reading order, and tables.

PDF.co is more appropriate when structured text, table, or document extraction is required.

Can PDFsharp merge and split PDFs?

Yes. Merging and splitting are among PDFsharp’s primary PDF-processing capabilities.

PDF.co also provides hosted merge and split endpoints.

Does PDFsharp support digital signatures?

Current PDFsharp 6.2 documentation describes CMS-based digital-signature support, including certificate-based signing and extensible signer implementations.

A digital signature requires proper certificate, private-key, timestamp, and validation management. It is not the same as placing a signature image on a page.

Does PDFsharp support PDF forms?

PDFsharp provides access to PDF structures and some AcroForm functionality, but high-level form support is limited. Test the exact documents and form operations required by your application.

Is PDFsharp a PDF viewer?

No. PDFsharp does not render, display, or print PDF pages by itself.

A separate PDF viewer or rendering component is needed.

Can PDFsharp be used as an API?

A development team can build a REST API around PDFsharp, but PDFsharp does not supply the hosted API infrastructure.

The team must implement authentication, endpoints, queues, scaling, file handling, logging, and monitoring.

Which is better for Bubble, Zapier, Make, or n8n?

PDF.co is usually easier for these environments because it provides HTTP endpoints that can be called directly from workflow tools.

Using PDFsharp normally requires a separately hosted .NET backend.

Which is better for private on-premises processing?

PDFsharp is generally the more natural choice when files must remain within infrastructure controlled by the organization.

The organization is then responsible for securing and operating the document-processing environment.

Final Verdict

PDFsharp and PDF.co should not be evaluated as interchangeable PDF products.

PDFsharp is a strong choice for .NET developers who want an open-source, self-hosted library for creating, drawing, merging, splitting, encrypting, signing, and modifying PDFs.

PDF.co is a stronger choice when the workflow requires a language-independent API, HTML rendering, PDF-to-image conversion, OCR, structured extraction, document parsing, barcode processing, or low-code integrations.

Choose PDFsharp when control, local processing, .NET integration, and MIT licensing are the priorities.

Choose PDF.co when breadth of document operations, implementation speed, managed processing, and cross-platform workflow automation are more important.

For many production systems, the most practical architecture is not an exclusive choice. PDFsharp can handle fast and controlled local operations, while PDF.co handles specialized conversion, OCR, rendering, and extraction tasks through a managed API.

Explore the PDF.co API documentation or review current PDF.co plans to estimate the requirements for your workflow.