Convert PDF to HTML
A PDF that will not reflow on a phone becomes a web page with real headings and paragraphs that search engines can index and screen readers can follow. Use it to publish report archives or move old brochures into your site. You pay per conversion, with no subscription.
This task is not available right now, so it cannot be purchased. Nothing is charged for it.
How it works & APIstructured output
Why a PDF struggles on the web
A PDF is built to look identical on every screen and printer, and that is exactly what makes it awkward on a website. It does not reflow on a phone, so readers pinch and zoom a page designed for paper. Its text is mostly invisible to on-page search, and a screen reader has trouble with content that is really just positioned glyphs. HTML solves all three because it describes content and structure instead of fixed ink placement. The two formats were born from different problems: HTML to adapt to whatever device shows it, PDF to guarantee the same page everywhere. Moving between them is genuine translation work, not a file-extension swap.
When converting to HTML pays off
The typical case is a backlog of reports or manuals sitting behind a download button nobody clicks. As HTML pages they can be indexed by search engines and linked to directly. Fixed-layout documents become readable on any phone, and headings become navigable for screen readers and other assistive tools. Old brochures and datasheets can move into a content management system as editable blocks, styled with the look the site already has. If a document truly cannot be converted, it is retried up to three times before you receive a clear error, so a large migration does not stall on one stubborn file.
Why a PDF and a web page are not the same thing
A PDF is built to look identical everywhere, on any screen or printer, which is exactly what makes it a poor citizen on the web: it does not reflow on a phone, it is invisible to most on-page search, and a screen reader struggles with content that is really just positioned glyphs. HTML solves all three by describing content and structure rather than fixed ink placement.
Two formats built for opposite purposes
HTML and PDF were born from different problems: HTML to let content adapt to whatever device renders it, PDF to guarantee a page looks the same no matter what opens it. Both have thrived because neither purpose went away — but that also means moving between them is genuine translation work, not a file-extension swap.
What you can do with it
Publishing PDF archives to the web
Turn a backlog of PDF reports or manuals into HTML pages that can be indexed by search engines and linked to directly, instead of sitting behind a download button no one clicks.
Responsive reading on any device
Convert fixed-layout PDFs into HTML that reflows properly on a phone screen, so readers are not stuck pinching and zooming a document designed for a printed page.
Accessibility improvements
Rebuild PDF content as semantic HTML so screen readers and other assistive tools can navigate headings and text properly, something a flat PDF layout rarely supports well.
Feeding a CMS with legacy content
Move a library of old PDF brochures or datasheets into a content-management system as editable HTML blocks, ready to be styled with the site's existing CSS.
FAQ
Will there be a free tier or free trial?
There's no free tier — free tiers get abused and slow everyone down. No subscription, no tokens, no invented credits, and a failed task is never charged.
Will it preserve headings, paragraphs and structure?
Yes — the goal is real HTML markup that reflects the document's structure, not an image or a pixel-positioned reproduction of the page.
How is PDF to HTML different from PDF to Markdown?
HTML output is meant to be styled and embedded directly in a web page with CSS, while Markdown output is meant for plain-text editing, version control, and documentation tools.
What happens to my files, and is there a retry policy?
Failed tasks will be retried automatically up to three times before returning a clear error, with no charge for failures. Source PDFs and generated HTML will be deleted after the retention window and never used to train anything.
Can I style the converted HTML like the rest of my site?
Yes. The result is real HTML with headings and paragraphs rather than a picture of the page, so it takes your site's own styles and can go into a content management system as editable blocks.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
One authenticated POST creates the task; the result comes back by webhook or a signed link. This capability is currently available through the API, not as an interactive Web tool.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/pdf/to-html \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"pdf":"https://example.com/document.pdf"}'const res = await fetch("https://api.kit.forhosting.com/pdf/to-html", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"pdf": "https://example.com/document.pdf"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/pdf/to-html",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"pdf": "https://example.com/document.pdf"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/pdf/to-html", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"pdf":"https://example.com/document.pdf"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"pdf":"https://example.com/document.pdf"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/pdf/to-html", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"pdf": "https://example.com/document.pdf"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "pdf.to_html",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_mb | 25 |
max_pages | 200 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
413 | input_too_large | The file exceeds the size limit. |
Technical notes
This endpoint reads a PDF's layout and rebuilds it as real HTML — tags for headings and paragraphs, elements positioned the way the original page was, not a screenshot pretending to be a document. It is meant for the moment a PDF needs to live inside a web page instead of behind a download link.
Why a PDF and a web page are not the same thing
This endpoint exists for teams that have documents locked in PDF but need them to behave like actual web content — indexable, responsive, and stylable with CSS.
What a request will look like
You will POST the PDF to /pdf/to-html and receive a task_id immediately, since reconstructing markup from a fixed-layout format takes real analysis. Once conversion finishes, the HTML is delivered to your webhook or made available at a signed link valid for 24 hours — the same asynchronous pattern used across every endpoint here, so it plugs into a pipeline you may already be running for other conversions.
Two formats built for opposite purposes
Reconstructing headings, paragraph flow, and structure from a format that was never designed to expose them is the specific problem this endpoint is built to solve.
Where it will fit into your stack
Expect the same automation-friendly shape as the rest of the API: a task_id on submission, a webhook on completion, and automatic retries — up to three — before a clear error is returned for a document that truly cannot convert. That means a bulk migration of PDF archives into an HTML-based CMS or documentation site can run unattended, converting hundreds of files and reacting to each one as it finishes rather than polling a queue.
Status, pricing and data handling
This endpoint is in deployment and not yet accepting jobs, but the pricing is already set and published: $0.052 per request plus $0.003 per page. Once live, access will require prepaid balance like every other endpoint — a request without one returns a 402 by design, keeping the service fast and abuse-free for everyone using it. As with the rest of the API, source PDFs and generated HTML are kept only through the retention window, then deleted, and are never used to train anything.
Technical questions
Is the PDF to HTML API available now?
It is in deployment and not yet accepting jobs, but the endpoint, pricing, and behavior are already defined and will follow the same async pattern as the rest of the API.
How will I convert a PDF to HTML with the API?
You will POST the PDF to /pdf/to-html and receive a task_id right away; the converted HTML will arrive on your webhook or a signed link once processing finishes.
How much will PDF to HTML conversion cost?
The published price is $0.052 per request plus $0.003 per page, so a ten-page document will cost about $0.082.
Will bulk conversion be supported?
Yes — each PDF will run as an independent task with its own task_id, so batches of files can be processed in parallel and tracked through their individual webhooks.