ScreenshotNeo

BlogComparisons

Html2Pdf.app Alternatives for Converting URLs to PDF with an API

Compare four documented HTML-to-PDF APIs by input type, rendering controls, delivery, and document requirements, then choose with a representative bake-off.

By the ScreenshotNeo team4 October 202613 min read

If you need a hosted API that converts a public URL or generated HTML into a PDF, the main alternatives to compare with HTML2PDF.app are PDFCrowd, DocRaptor, and Browserless. The right choice depends on whether you need file or template inputs, asynchronous delivery, print layout controls, or document tagging and archival features. Documentation confirms advertised capabilities; it does not establish which service renders your documents best. Run a small bake-off with representative pages before committing.

ScreenshotNeo is an alternative to try first when your actual output requirement is a clean website screenshot rather than a selectable-text PDF. It returns PNG, JPEG, WebP, or PDF and removes supported consent banners, newsletter popups, and chat widgets before capture. A screenshot-oriented PDF is not a drop-in replacement for a paginated, searchable, accessible, or archival document. See ScreenshotNeo and its API documentation.

1. Compare the alternatives by workload

Service Documented fit Questions to verify
ScreenshotNeo Try it first for clean visual captures from a URL, including PDF output. Cookie/consent banners, newsletter popups, and chat widgets are removed before capture; each step can be disabled. Only clean shots are billed, and response headers identify page verdict and billing. Is a page capture PDF sufficient, or do you require paginated print layout, selectable text, PDF/A, or accessibility conformance? Check the docs for capture and PDF parameters.
PDFCrowd HTML to PDF API URL, raw HTML, uploaded files, and templates; language SDKs; controls include page composition, JavaScript readiness, watermarks, password protection, PDF/A, and tagged PDF. Check whether the exact output controls satisfy the document requirement and whether current plan limits and price fit expected volume.
DocRaptor HTML to PDF API JSON POST for PDF generation from HTML, with binary, hosted-document, and asynchronous response options. Verify that its rendering and document features meet your actual layout and compliance requirements.
Browserless PDF API REST /pdf endpoint for URL or raw HTML input, implemented with Puppeteer; options include page ranges and tagged output. The REST endpoint does not create a single continuous full-page PDF. Tagged output is not certified PDF/UA, and markup quality affects the result. For custom full-page output, its docs point to the /function API.
HTML2PDF.app Authenticated POST with a public URL or raw HTML; synchronous PDF bytes or callback flow; Chromium-based rendering and print settings. Confirm public reachability, resource and script readiness, callback processing, account limits, and data-handling requirements. Keep the API key server-side.

These are capability comparisons from provider documentation, not a finding that one service produces superior files. Provider-listed pricing and limits change; check each provider before purchase.

2. Decide what “PDF” means for your application

Before comparing vendors, specify the artifact your users need. A browser print PDF is usually a paginated document with selectable text. A screenshot saved as PDF preserves visual appearance but may not behave like a well-structured document for search, accessibility, copying, or archival workflows.

  • Public URL or generated HTML: HTML2PDF.app, DocRaptor, PDFCrowd, and Browserless document URL/HTML workflows. PDFCrowd also documents file and template inputs.
  • JavaScript-heavy page: Check how each service waits for application data, fonts, and images. HTML2PDF.app specifically cautions that JavaScript timing, CSS media mode, and available fonts/resources affect results.
  • Print layout: Validate page size, margins, orientation, background colors, page breaks, headers, and footers using your real documents.
  • Async volume: DocRaptor documents asynchronous generation and hosted documents; HTML2PDF.app documents callbacks. Decide how jobs are correlated, retried, stored, and delivered.
  • Compliance: Check PDF/A, tagging, encryption, and any formal accessibility or archival standard separately. “Tagged” does not by itself mean certified conformance.
  • Clean visual capture: If you want to remove consent banners, popups, and chat overlays from a website capture, evaluate ScreenshotNeo. This is a screenshot workflow, not a general-purpose document rendering or PDF/A API.

3. Evaluate ScreenshotNeo for clean URL captures

For developers whose requirement is to capture a website view and return an image or PDF, ScreenshotNeo is the first alternative to try. It accepts one GET request with the target URL and can return PNG, JPEG, WebP, or PDF. Before capture, it accepts the cookie/consent banner as a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets. Each step can be turned off. Bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing; response headers report the page verdict and whether the request was billed.

ScreenshotNeo also offers an MCP server for AI agents and supports options such as full-page capture with lazy images loaded, CSS element capture, viewport/device presets, dark mode, retina scale, custom CSS and JavaScript, selector waits, cookies and headers, request blocking, caching, async jobs, bulk capture, and PDFs with paper and margin settings. Every feature is available on every plan. Pricing is Free for 1,000 shots/month with no card; Starter $5 for 3,000; Growth $15 for 15,000; Pro $39 for 60,000; Scale $99 for 250,000; and Business $249 for 1,000,000. Yearly billing gives two months free.

If your PDF needs page ranges, formal PDF/A output, or tagged document structure, compare the document APIs below against those requirements rather than assuming a capture PDF is equivalent.

4. What each document API offers

PDFCrowd

PDFCrowd is worth evaluating when your sources include more than URLs and inline markup: its documentation includes uploaded files and templates as well as URL and HTML conversion. Its API overview also lists SDKs and controls for page composition, JavaScript readiness, watermarks, password protection, PDF/A, and tagged PDFs. Confirm the options you need in its current API docs, then verify the output against your own documents. The documented feature list is not a comparative quality test.

DocRaptor

DocRaptor documents a JSON POST for generating a PDF from HTML and multiple delivery patterns: return PDF bytes, create a hosted document, or generate asynchronously and retrieve by status identifier. This can suit an application that should not hold a client request open while a document is generated. Verify its rendering features and output against your page layout and compliance needs.

Browserless

Browserless documents a /pdf endpoint that accepts a URL or raw HTML and renders through Puppeteer. Its options include print configuration, page ranges, and tagged output. For long documents it describes splitting with page ranges and merging the results; ranges must cover every page, since uncovered pages can be silently omitted. Each chunk reloads the source, so time-dependent or personalized content can differ. The endpoint does not make one continuous full-page PDF; the documentation directs that use case to its /function API. Tagged output is not certified PDF/UA.

HTML2PDF.app baseline

HTML2PDF.app documents one authenticated POST to https://api.html2pdf.app/v1/generate. Put a public URL or raw markup in the required html field. Synchronous success returns PDF binary data. Add callBackUrl to run a background conversion; the callback JSON carries a base64-encoded document, and an optional state value is returned unchanged. The API key belongs in a backend or trusted job, never browser JavaScript or a public repository. Read the HTML2PDF.app API documentation for current request details.

5. Run a representative bake-off

  1. Build a fixed test set. Include a simple page, a JavaScript-rendered report, custom fonts, long tables, explicit page breaks, headers and footers, and any authenticated page you must support.
  2. Make input equivalent. Send the same URL or same generated HTML, same assets, and same data to each candidate. Avoid comparing a hosted URL in one service with a hand-edited HTML version in another.
  3. Set output requirements first. Specify paper size, orientation, margins, page-break rules, background printing, page numbering, password or permissions, and any PDF/A or tagging requirement.
  4. Inspect the actual files. Check missing fonts and images, clipped content, blank pages, unexpected page splits, selectable text, reading order where relevant, and final file size.
  5. Measure your workload. Record wall-clock latency, timeout rate, error handling, retry behavior, and total cost at realistic request volume and output size. No side-by-side benchmark is available in this research.
  6. Review operations and data terms. Confirm concurrency and plan limits, retention, privacy, callback security, and what happens on failure. Keep conversion credentials and sensitive source data on the server.

A small bake-off is more useful than extrapolating from implementation labels. HTML2PDF.app documents headless Chromium; Browserless documents Puppeteer; neither fact proves fidelity for your particular pages.

6. Request and response handling

Most PDF APIs return binary data on a successful synchronous request. Treat status codes and content types as part of the API contract: an error response saved with a .pdf suffix is still an error, not a document. For asynchronous jobs, persist your own job identifier and make callback processing idempotent.

HTML2PDF.app: cURL

curl --fail --show-error \
  --request POST https://api.html2pdf.app/v1/generate \
  --header 'Content-Type: application/json' \
  --header "X-API-Key: $HTML2PDF_API_KEY" \
  --data '{"html":"https://www.example.com","format":"A4","media":"print"}' \
  --output document.pdf

HTML2PDF.app: Python

import os
import requests

response = requests.post(
    "https://api.html2pdf.app/v1/generate",
    headers={
        "Content-Type": "application/json",
        "X-API-Key": os.environ["HTML2PDF_API_KEY"],
    },
    json={"html": "https://www.example.com", "format": "A4", "media": "print"},
    timeout=90,
)
response.raise_for_status()
if "application/pdf" not in response.headers.get("Content-Type", ""):
    raise RuntimeError("Successful response did not have a PDF content type")
with open("document.pdf", "wb") as output:
    output.write(response.content)

HTML2PDF.app: Node.js

import { writeFile } from 'node:fs/promises';

const response = await fetch('https://api.html2pdf.app/v1/generate', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-API-Key': process.env.HTML2PDF_API_KEY,
  },
  body: JSON.stringify({
    html: 'https://www.example.com',
    format: 'A4',
    media: 'print',
  }),
  signal: AbortSignal.timeout(90000),
});
if (!response.ok) {
  throw new Error(`PDF generation failed: HTTP ${response.status} ${await response.text()}`);
}
if (!response.headers.get('content-type')?.includes('application/pdf')) {
  throw new Error('Successful response did not have a PDF content type');
}
await writeFile('document.pdf', Buffer.from(await response.arrayBuffer()));

These examples use the documented endpoint and authentication. Store the key in an environment secret or secret manager. See HTML2PDF.app’s full documentation for all parameters and callback handling.

Browserless: minimal cURL request

curl --fail-with-body --show-error \
  --request POST 'https://production-sfo.browserless.io/pdf?token=YOUR_API_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{"url":"https://example.com/","options":{"format":"A4","printBackground":true}}' \
  --output document.pdf

Browserless accepts either url or html in its JSON body, not both. This sample uses its documented endpoint form; select the correct endpoint for your account and region. Check HTTP status before using the file.

7. HTML2PDF.app options and rendering details

The documented request accepts the following options. Defaults and valid values can change; check the current provider documentation when implementing.

Parameter Use Notes
html Required source: public URL or raw HTML string. URL must be reachable by the rendering service. Use POST JSON for raw or long HTML.
format Paper size: Letter, Legal, Tabloid, Ledger, A0–A6; default A4. For custom dimensions use width and height together.
landscape Boolean orientation switch; default false. Set deliberately and test wide tables/charts.
width, height Custom page dimensions in pixels. Use both parameters together.
marginTop, marginRight, marginBottom, marginLeft Page whitespace in pixels; defaults are zero. Reserve space for headers and footers.
media CSS media mode, print or screen; default screen. Print styles can hide or restyle content. Test both if the target site has separate stylesheets.
scale Content scale from 0.1 to 2; default 1. Use only after checking layout and text size; scaling can affect page breaks.
waitFor Wait a number of seconds before rendering, from 0 to 10. Useful for delayed JavaScript or resources, but a fixed wait adds latency and does not guarantee a specific app state.
headerTemplate, footerTemplate HTML for repeated page header/footer. Use classes date, title, url, pageNumber, and totalPages. Templates do not inherit page CSS and cannot fetch external images; embed images as data URLs.
filename Set the returned filename. Does not change PDF content.
userPassword, ownerPassword, permissions Encrypt and constrain PDF actions. Use a deliberate permissions policy; do not treat PDF password protection as a replacement for access control over the source or delivery.
callBackUrl, state Queue asynchronous conversion and correlate its callback. Callback includes base64 PDF in document; process duplicate delivery safely.

For raw HTML, escape JSON correctly by using a JSON serializer rather than string concatenation. External scripts, fonts, and images must be available to the rendering browser. A page that depends on user-specific browser state may not render as it does in your own logged-in session.

8. Troubleshooting

Symptom Likely cause What to do
HTML2PDF.app returns 400 Source URL is not accessible or a parameter is invalid. Check public reachability, spelling, parameter names, and supported values. Do not retry unchanged input.
HTML2PDF.app returns 401 Missing or invalid X-API-Key. Check the server-side secret and request header. Rotate or replace an invalid key.
HTML2PDF.app returns 403 Account plan limit reached. Review current plan limits and account notices before retrying.
HTML2PDF.app returns 500 Unhandled service error. Retry after a short delay with increasing backoff; contact support if it persists. Avoid unbounded retry loops.
Saved “PDF” is JSON, HTML, or plain text Error body was saved without checking HTTP status. Check status before writing/serving bytes. For other APIs, inspect the provider’s error response and content type.
Blank or partly rendered output Page blocked from the renderer, JavaScript not finished, or assets failed to load. Verify URL accessibility from outside your browser; check scripts, images, fonts, and network dependencies. Use a bounded wait or readiness option supported by the provider.
Wrong colors or layout Screen versus print CSS, backgrounds, scaling, or paper size differ. Set media and print-background options explicitly, then inspect page dimensions and CSS print rules.
Font substitution or missing glyphs Font URL failed, font had not loaded, or needed glyphs are unavailable. Make font resources reachable, wait for readiness, and test non-Latin and right-to-left scripts if applicable.
Headers/footers overlap or disappear Reserved page margin is too small, or template styles/resources are missing. Increase top/bottom margins; include CSS in the template itself and embed image assets.
Long Browserless output misses pages Page-range chunks did not cover the whole document. Calculate ranges from the actual page count, cover every page, validate each chunk, and account for each request reloading the source.
Webhook job appears lost or duplicated Callback delivery is delayed, retried, or handler is not idempotent. Store the correlation state, accept duplicate callbacks safely, and track queued, received, processed, and failed states.

9. Performance, reliability, and cost

Measure conversion latency using your own pages: JavaScript execution, resource loading, page count, and output size can all affect a render. A fixed delay can improve timing for a known page but increases every request’s duration. Prefer a provider-supported readiness condition when available. Bound request timeouts and concurrency to match your application’s user-facing latency budget.

For reliability, distinguish transient failures from invalid input and account limits. Retry transient server/network failures with exponential backoff and a maximum attempt count; do not blindly retry authentication, validation, or plan-limit errors. For asynchronous delivery, persist job state and make handlers idempotent. Verify generated bytes before returning them as application/pdf.

Compare total cost at expected usage, not a headline starting price alone. Include request volume, output size, plan and concurrency limits, async or hosted delivery needs, and operational work. HTML2PDF.app’s product page lists Free at $0/month with 100 credits and files up to 1 MB, Startup at $9/month for 1,000 credits, Standard at $25/month for 5,000, and Scale at $39/month for 10,000; it says each 5 MB chunk of generated document uses one credit. These are provider-listed figures observed in the research pass on 2026-10-03, not independent benchmarks, and should be rechecked before a purchase decision. Current prices and limits for every provider should be confirmed directly.

For clean website screenshots, ScreenshotNeo’s stated billing rule is that only clean shots are billed: bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, with verdict and billing information in response headers. Its free tier includes 1,000 shots monthly with no card; paid plans start at $5 for 3,000. This is a different workload and cost model from general-purpose paginated PDF conversion.

10. Or skip the browser setup

For a URL capture returned as PDF, ScreenshotNeo provides one GET request. This produces a screenshot-style PDF, so use a document conversion API when you need structured, paginated text output.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.pdf

Read the ScreenshotNeo API docs for output and capture parameters. Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. Sign up for ScreenshotNeo and get 1,000 free screenshots each month, with no card required.

FAQ

Which alternative should I try first?

For conventional URL-to-PDF conversion, shortlist PDFCrowd, DocRaptor, and Browserless based on the inputs and controls you need, then test representative documents. For a clean visual website capture, try ScreenshotNeo first; it is not a substitute for every document-PDF requirement.

Can I convert a page that requires login?

Do not assume a URL converter shares your logged-in browser session. Confirm that the service supports the authentication method your page needs, and avoid sending sensitive credentials or data until you have reviewed its security and data terms.

Will a tagged PDF meet an accessibility standard?

Not automatically. Browserless explicitly says its tagged output is not certified PDF/UA, and document quality depends on source markup. Validate against the specific standard your application requires.

Is a screenshot PDF searchable?

Do not assume it is equivalent to a rendered document PDF with selectable text and structure. If search, copying, screen-reader structure, or formal archival conformance matters, generate and validate a document PDF designed for that need.

Sources

Provider documentation was used to establish advertised capabilities. No service was tested and no side-by-side rendering, latency, or reliability benchmark was conducted.