Is Html2Pdf.app Worth It for a Small Website? Review and Limitations

Is Html2Pdf.app worth it for a small website? It can be, if your site already has a backend, you need automated PDFs, and your output sizes, monthly volume, and peak concurrency fit its published limits. It is less compelling if you need one-off manual conversions, have strict data-handling requirements you have not verified, or cannot tolerate output differences without testing your own pages.

Html2Pdf.app is a hosted HTML-to-PDF API, with a WordPress plugin. Its documentation accepts either a publicly reachable URL or raw HTML, authenticates API requests with a key, and describes synchronous and callback-based asynchronous conversion. The documented renderer is headless Chromium. These are vendor-published capabilities, not independent evidence of rendering quality, uptime, or support.

This review uses the vendor’s published documentation and pricing. It does not claim hands-on testing. The practical decision is to estimate your real PDF sizes and workload, test representative pages, and compare the resulting cost and operational fit with alternatives.

What the free and paid plans include

The pricing page counts credits by output size: each 5 MB chunk of generated PDF output consumes one credit. That means a request is not necessarily one credit. A PDF near 6 MB uses more credits than a PDF under 5 MB under this published rule. Check the current pricing page before committing because rates and terms can change.

Plan	Published monthly price	Credits/month	Parallel conversions	PDF size limit
Free	$0	100	1	Up to 1 MB
Startup	$9	1,000	3	See current plan terms
Standard	$25	5,000	10	See current plan terms
Scale	$39	10,000	20	See current plan terms

These figures are the vendor’s listed monthly prices and limits. The pricing page has a yearly option, but the available evidence does not establish its yearly prices or discount. Do not extrapolate a yearly amount from the monthly tiers. An independent pricing page checked vendor prices on 2026-09-29; that is a dated price cross-check, not an independent product review.

Estimate credits before choosing a plan

Measure or estimate the generated PDF size for representative pages.
Convert the expected output size into 5 MB chunks, following the provider’s credit rule.
Multiply by the expected number of conversions in a month, allowing for retries and seasonal peaks.
Check whether simultaneous jobs fit the plan’s parallel conversion allowance.
Compare that usage with the current plan limits and price.

For instance, a site that produces small documents may fit more jobs into its credit allowance than a site producing image-heavy PDFs. The relevant unit is generated output size, not simply the number of API calls. Confirm how the current service rounds sizes and handles account limits in its documentation before using a precise cost forecast.

When it is a sensible choice for a small website

You already have a trusted server-side environment. A backend, server-side script, or trusted job can keep the API key private.
PDF creation is a repeatable product feature. Examples include invoices, reports, or user-requested exports generated from a URL or HTML your system controls.
Your usage is predictable enough to budget. You can estimate output sizes, monthly conversions, and concurrent jobs.
Your documents render acceptably in your own evaluation. Fonts, remote resources, CSS media choice, and JavaScript timing can change results.
The cost of operating PDF infrastructure yourself is greater than the API cost for your workload. This is a business comparison to make from your own engineering and usage costs; the published plan prices alone cannot settle it.

It may be a poor fit if you need unbounded output, high burst concurrency beyond your plan, a rendering guarantee the documentation does not establish, or a data-handling commitment you have not reviewed. A free plan’s 1 MB PDF limit and single parallel conversion are particularly relevant constraints for an initial pilot.

How to make a server-side PDF request

The documented endpoint is https://api.html2pdf.app/v1/generate and requests use an X-API-Key header. The examples below show the request shape for a URL input. Set the key in a server-side secret or environment variable; do not put it in browser code, a public repository, or a client-side template. Use a source URL that the service can access.

cURL

export HTML2PDF_API_KEY='YOUR_API_KEY'
curl --fail-with-body --silent --show-error \
  --request POST 'https://api.html2pdf.app/v1/generate' \
  --header "X-API-Key: ${HTML2PDF_API_KEY}" \
  --header 'Content-Type: application/json' \
  --data '{"url":"https://example.com/"}' \
  --output page.pdf

This illustrates a URL request and binary output handling. Confirm the exact JSON field names and supported options in the current official documentation before deployment. Check the HTTP status: a successful synchronous response contains PDF bytes, while an error response should not be saved and treated as a PDF.

Python

import os
import requests

api_key = os.environ["HTML2PDF_API_KEY"]
response = requests.post(
    "https://api.html2pdf.app/v1/generate",
    headers={
        "X-API-Key": api_key,
        "Content-Type": "application/json",
    },
    json={"url": "https://example.com/"},
    timeout=90,
)
response.raise_for_status()

content_type = response.headers.get("content-type", "")
if "pdf" not in content_type.lower():
    raise RuntimeError(f"Expected PDF response, received {content_type!r}")

with open("page.pdf", "wb") as output:
    output.write(response.content)

Node.js

const apiKey = process.env.HTML2PDF_API_KEY;
if (!apiKey) throw new Error('Set HTML2PDF_API_KEY in the server environment');

const response = await fetch('https://api.html2pdf.app/v1/generate', {
  method: 'POST',
  headers: {
    'X-API-Key': apiKey,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ url: 'https://example.com/' }),
  signal: AbortSignal.timeout(90_000),
});

if (!response.ok) {
  throw new Error(`PDF conversion failed: HTTP ${response.status} ${await response.text()}`);
}
const contentType = response.headers.get('content-type') || '';
if (!contentType.toLowerCase().includes('pdf')) {
  throw new Error(`Expected PDF response, received ${contentType}`);
}
const pdf = Buffer.from(await response.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('page.pdf', pdf));

The samples use a URL input because it is straightforward to demonstrate. The API documentation also describes raw HTML input. For either input type, review the documented request schema, required fields, and response behavior at the official documentation. Keep authentication and conversion on a server you control.

Options that can affect the PDF

The documentation describes options for orientation, standard paper formats, custom width and height, margins, output filename, JavaScript wait time, print or screen media mode, scale, header and footer HTML, PDF passwords, and permissions. Treat these as controls to evaluate against your output requirements; an available parameter does not ensure every source page will render exactly as expected.

Concern	What to decide	What to inspect in the output
Page geometry	Orientation, paper format or custom dimensions, and margins	Clipping, unexpected blank space, and page breaks
CSS media	Whether print or screen styling is appropriate	Visibility, colors, layout, and print-specific rules
Dynamic content	How much time JavaScript needs before capture	Missing charts, incomplete data, and loading placeholders
Scale	Whether to fit content or preserve readable sizing	Text size and page count
Headers and footers	Whether repeated page information is needed	Overlap with document content and page numbering
Security controls	Whether passwords or permissions are appropriate	Whether the intended reader can open and use the document

Use only documented parameter names and values. The research evidence does not provide a complete request schema or every allowed enum value, so this article does not invent a supposedly exhaustive JSON configuration. Consult the official docs for the current schema when adding options.

Test rendering before production

Headless Chromium supports modern HTML, CSS, and JavaScript according to the vendor documentation. The same documentation cautions that media mode, available fonts and resources, and JavaScript timing affect results. A small-site evaluation should test real pages rather than infer fidelity from the renderer name.

Choose representative pages: the shortest and longest documents, pages with remote images, custom fonts, charts, and any content assembled by JavaScript.
Try the print and screen media modes where both are relevant.
Inspect page boundaries, missing or late content, font substitutions, margins, headers, and footers.
Record the resulting PDF file sizes and conversion time for your own workload.
Repeat the same cases after changing a relevant template or resource-loading behavior.

This is an evaluation procedure based on documented rendering variables, not a report that these cases were independently tested. If a page depends on authenticated resources or a private network, verify that the service can access the source before building a workflow around it.

Synchronous and asynchronous conversion

A synchronous request returns the PDF binary in the successful response. That is convenient when a user is waiting and the conversion reliably finishes within your request budget. The docs also describe callbacks for asynchronous work: the request is accepted, and the generated PDF is delivered through the callback workflow.

For asynchronous jobs, build an explicit state flow: submit the conversion, persist your own job identifier and expected result, accept the callback at a server endpoint, validate that callback according to the provider’s current instructions, and mark the job complete or failed. Make callback handling safe to retry so duplicate delivery does not create duplicate user-facing exports. Check the official documentation for the exact callback payload and authentication mechanism; they are not specified in the evidence summarized here.

Security and data handling

Keep the API key server-side. Do not expose it in browser JavaScript, public repositories, or templates sent to users. If users can submit a URL for conversion, validate that input according to your application’s security requirements and avoid treating arbitrary user-controlled URLs as trusted content.

Html2Pdf.app states that PDFs are processed temporarily rather than permanently stored on its servers, and that raw HTML/text is not stored in conversion logs. It also says selected metadata and a supplied source URL may be retained. These are vendor statements, not an independent audit or a compliance determination. Review the current privacy policy and data-processing terms against your own obligations before sending personal, confidential, or regulated information.

Alternatives and where ScreenshotNeo fits

If the job is to turn pages into PDFs through an API, compare providers using your actual document sizes, volume, concurrency, rendering tests, callback needs, key management, data terms, support evidence, and total cost. HTMLPDF.dev is another API provider to investigate; its presence as an alternative does not establish equivalent features or quality. Available evidence does not justify naming a winner between those PDF services.

ScreenshotNeo is the alternative to try first when your actual need is website screenshots or page capture, including PDF output, rather than a general HTML-to-PDF workflow. It is a website screenshot API and MCP server. One GET request can return a PNG, JPEG, WebP, or PDF; it also supports full-page capture, element capture, custom waits, and other capture controls. Its clean-shot processing accepts consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before capture. Each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, with the page verdict and billing status in response headers. It also offers MCP tools for AI clients.

Or skip the browser setup

For a website screenshot or PDF capture, call ScreenshotNeo’s API directly. See the ScreenshotNeo API documentation for request options and authentication.

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

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; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card.

Performance, reliability, and cost considerations

Size drives credit use. Each 5 MB chunk of PDF output equals one credit according to the current pricing page. Image-heavy output can therefore consume credits faster than compact documents.
Concurrency sets burst capacity. The published plans allow one, three, ten, and twenty parallel conversions respectively. Queue work in your own application if bursts may exceed the plan allowance, and verify current account-limit behavior.
Rendering time depends on the page. Remote resources and JavaScript can affect completion. Set timeouts appropriate to your application and decide how to handle a request that takes too long.
Reliability evidence is limited. The reviewed sources do not establish an independent uptime record, rendering benchmark, or support-response assessment. Evaluate with your own representative pages and operational needs.
Compare total cost, not just the tier label. Include expected PDF size, volume, concurrency, retries, engineering time, and the alternative cost of maintaining your own conversion setup.

Troubleshooting common failures

Symptom	Likely cause	What to do
Unauthorized or credential error	Missing, invalid, or incorrectly sent API key	Check the `X-API-Key` header and server-side secret; do not move the key into client code.
Source URL cannot be converted	The service cannot access the URL, or the request contains an invalid input	Check that the URL is reachable by the service and validate the request against the documented schema.
Invalid parameter response	An option name or value is not accepted	Compare parameter spelling, types, and allowed values with current documentation; remove options one at a time to isolate the issue.
Account limit or conversion rejected	Credits, file-size limit, or parallel capacity may have been reached	Inspect usage and plan limits, reduce output size, queue jobs, or select a plan whose published limits match demand.
PDF response is actually an error body	Client saved a non-success response as a file	Check HTTP status before writing output; log the error status and response body safely.
Fonts or images are missing	Resources are unavailable to the renderer or not loaded in time	Verify resource access and font loading; test again with the actual page and required media mode.
Charts or dynamic content are incomplete	JavaScript had not finished before rendering	Adjust the documented JavaScript wait option and confirm the page has reached the state you need.
Layout differs from the browser	Print versus screen CSS, page geometry, scale, or page breaks differ	Compare media modes and inspect margins, orientation, dimensions, and scale on representative pages.
Conversion is too slow for a user request	The source page or its assets take too long, or synchronous work exceeds your latency budget	Use a suitable timeout; consider the documented asynchronous callback flow for background work.

The vendor documentation lists inaccessible URLs or invalid parameters, missing or invalid credentials, account limits, and server errors among failure categories. For server errors, follow the provider’s current guidance, avoid aggressive retry loops, and make retries bounded and safe for your application.

Decision checklist

Have you estimated PDF output size and monthly credit use from real examples?
Does your expected peak job concurrency fit the published plan allowance?
Have you confirmed your source URLs are reachable and your fonts, images, and scripts load in the renderer?
Have you compared print and screen media output, page breaks, and headers or footers?
Is the API key kept in a trusted server environment?
Have you reviewed current data-retention terms for the content you plan to send?
Do you have a failure and retry path for account limits, timeouts, and server errors?

If the answers are yes and the price matches your measured usage, Html2Pdf.app is a plausible hosted option for a small website. Treat the fit as conditional on your own rendering and operational evaluation.

FAQ

Does Html2Pdf.app work with WordPress?

The product offers a WordPress plugin as well as its API. Confirm the plugin’s current features and setup instructions on the vendor site for your particular workflow.

Can I send raw HTML instead of a URL?

Yes. The official documentation describes both raw HTML and publicly reachable URL inputs. Follow its current request schema.

Is the free plan enough for production?

It may be enough for a small pilot with low usage, but its published limits are 100 credits monthly, up to 1 MB per PDF, and one parallel conversion. Whether that is enough depends on output size and traffic.

Has rendering quality or uptime been independently verified here?

No. The available evidence is primarily vendor documentation and pricing, plus a dated price cross-check. It does not establish independent rendering tests, uptime, or support quality.

Where can I check current pricing and API options?

See the provider’s pricing page and documentation before implementation, since limits and terms may change.

Sources

HTML2PDF.app pricing — published plans, credits, and concurrency.
HTML2PDF.app documentation — endpoint, inputs, options, callbacks, rendering notes, and errors.
iTechGuides pricing comparison — dated price cross-check.
HTMLPDF.dev — an additional provider to compare.