pdfrender vs SelectPdf
SelectPdf is a .NET HTML-to-PDF library with a hosted REST API on the side; pdfrender is API-first and language-neutral. Which shape suits you?
Last updated
| SelectPdf | .NET HTML→PDF library (installed in your app) plus a hosted online REST API; free tier and paid licenses/plans |
|---|---|
| pdfrender | API-only, language-neutral — nothing to install, works from curl, Python, Node, or any HTTP client |
SelectPdf's center of gravity is a .NET library: conversion runs inside your application process, licensed per developer/server, with a hosted REST API as a secondary offering. pdfrender is the inverse — there is no library at all. Rendering is one HTTP call from any language, and the engine, fonts and security patches are operated for you.
When SelectPdf is the better fit
- You are all-in on .NET and want conversion in-process — no network hop, no external dependency at runtime.
- Data-residency rules forbid sending document HTML to any external service.
When pdfrender fits
- Polyglot stacks: the same endpoint serves your Python, Node and shell code with zero installed dependencies.
- You would rather subscribe (free 100/month, €20/mo, €80/mo — cancel anytime) than manage library licenses and engine updates.
- No data retention by design: the PDF exists only in the response.
Try pdfrender free — no card, no install.
FAQ
- Is there a pdfrender library to install?
- No, by design. pdfrender is one HTTP endpoint, so the same call works from curl, Python, Node or any HTTP client with nothing installed and nothing to license.
- Can I run pdfrender inside my own application process?
- No. If in-process conversion or data residency is a hard requirement, a library such as SelectPdf — or self-hosting WeasyPrint — fits better.
- Does pdfrender store my HTML or the generated PDF?
- No. The PDF exists only in the response.