At a glance
Compare the shape of the work.
The table sticks to the official material linked below and to doclinth’s current product surface. Where a source does not establish a feature, the row says so.
| Decision point | PDFShift | doclinth |
|---|---|---|
| Primary input | Raw HTML and URLs are the primary documented PDF conversion inputs. | JSON is applied to a reusable HTML/Handlebars template; arbitrary URL-to-PDF conversion is not claimed. |
| Template and output modes | Stored templates, image output, S3/GCS export, and sandbox mode are documented alongside PDF conversion. | Draft and published templates produce PDF bytes or signed URLs; per-request render controls are available. |
| Data contract | The cited API reference is centered on conversion requests; it is not used here to claim a generated JSON Schema workflow. | Each template can expose a JSON Schema contract and generated TypeScript, Zod, or Pydantic types. |
| Layout confidence | Use the documented sandbox and conversion workflow to validate your HTML; no additional product claim is inferred here. | Named fixtures and schema-driven PDF layout stress tests check long data, rows, optional fields, and other document pressure before release. |
| Automation surface | The cited API reference documents conversion and storage/export options. | Use Node.js/Python SDKs, OpenAPI, llms.txt, asynchronous webhooks, idempotency, logs, and a remote MCP server. |
Decision guide
The right choice depends on the owner of the document.
If the current workflow is the fit
Choose PDFShift if…
- your application already produces complete HTML or a URL and conversion is the main problem to solve
- image output, stored templates, S3/GCS export, or sandbox mode are part of the documented workflow you need
- you want to keep the document layout in the HTML page or URL that your system already owns
If the document is a product surface
Choose doclinth if…
- you want to keep application data separate from a reusable document layout and publish versions deliberately
- you want a typed contract and layout-test workflow around every template rather than only a conversion request
- you want an API surface designed for SDK callers and AI agents as well as ordinary HTTP services
Migration / decision checklist
Keep the acceptance target. Change the boundary carefully.
The key migration question is whether your current HTML is a finished page or a document template in disguise. Keep the former as a reference, then move repeated structure and data fields into a doclinth template only where that gives your team a clearer release boundary.
- 01Group the current PDFShift requests by input type: complete HTML, URL, or stored template. Record which values are generated by application code.
- 02Select one repeated document and turn its layout into an HTML/Handlebars template; use PDF import or prompt authoring to accelerate the first draft when useful.
- 03Define the JSON payload, fetch its schema, and generate the type used by the service that calls doclinth.
- 04Create fixtures for the current representative output and for the HTML edge cases that have historically caused layout drift; run document tests.
- 05Decide whether callers need PDF bytes or signed URLs, then add webhooks and idempotency for jobs that should not wait on a single request.
Continue with doclinth
Read the surfaces that make the workflow real.
- API docs Start with the generate flow and the public API shape.
- Template syntax See the HTML and Handlebars building blocks.
- Template gallery Browse ready-made documents for common business workflows.
- Pricing Review the current plans without committing to a migration.
- Import a PDF Turn an existing PDF into an editable draft workflow.
- Document tests Stress layouts with named fixtures and schema-driven variants.
- Node.js SDK Use the typed client for Node.js and TypeScript services.
- AI agents and MCP Connect an agent through the remote MCP server or HTTP API.
Questions worth settling before a switch
PDFShift, in plain terms.
- Is doclinth a raw HTML or URL-to-PDF replacement for PDFShift?
- No. PDFShift’s documented workflow centers on raw HTML and URLs. doclinth expects JSON to populate a reusable HTML/Handlebars template and does not claim arbitrary URL-to-PDF conversion.
- Can doclinth use a stored template?
- Yes, in a different model. doclinth keeps draft and published versions of reusable templates; callers send JSON with the template identity instead of sending a complete page or URL as the primary input.
- Does doclinth support S3 or GCS export?
- This page does not claim native S3 or GCS export for doclinth. doclinth can return PDF bytes or a signed URL, so choose the handoff that fits the storage layer in your application.
- When should I keep a conversion workflow instead of moving to a template workflow?
- Keep conversion when your system already owns a complete HTML page or URL and that is the stable artifact you want to print. Consider doclinth when repeated documents need explicit JSON contracts, published versions, fixtures, and layout tests.
Sources and scope
Official material used for this comparison
doclinth is not affiliated with PDFShift. Product names and logos may be trademarks of their respective owners. This page is a workflow comparison, not a claim of partnership, endorsement, compliance certification, guaranteed ranking, or unsupported performance.