PDF to HTML & Text Converter
Extract available text from a PDF, or generate an approximate HTML layout from its text layer — with clear limits for reading order, fonts, and visual fidelity.Extract text from a PDF, or generate a positioned HTML approximation of the page — each with a different level of fidelity, explained honestly below.
The extraction console
Upload a PDF, preview its pages, and start conversion.
Drag & drop a PDF file here, or
Two outputs, two very different reliability levels
Both come from the same source — pdf.js reading the text layer already embedded in your PDF — but what happens next to that text is completely different between the two tabs.
Text tab — reliable
Every character pdf.js reads from the page is joined together, in the order the PDF's internal content stream presents it. Nothing is approximated or reconstructed — this is the same text extraction search and copy-paste rely on.
For single-column documents like letters, articles, and most reports, this reads in the correct order. For multi-column layouts and tables, the internal stream order doesn't always match visual reading order, so content can come out jumbled.
HTML tab — approximate
Each piece of text is placed at its original x/y position using absolutely-positioned elements, with a horizontal scale calculated from an estimated average character width — not real font metrics, so spacing can look stretched or compressed for some strings.
The font-family declaration uses pdf.js's internal font identifier, which isn't a real, browser-usable font name. The rendered text uses your browser's default font, not the PDF's actual typeface. Treat this as a structural sketch, not a visual copy.
The Text tab is the reliable one
Reach for HTML only when you specifically need position information — otherwise, Text is almost always the better choice.
Upload your PDF
Drag it onto the upload area, or click Browse File. Page previews appear instantly.
Start the conversion
Click Start Conversion. Both outputs are generated at once:
Check which tab you need
Reading, editing, or repurposing content? Use Text. Need approximate on-page position? Try HTML, with fonts expected to differ.
Download or copy
Download the active tab as a file, or copy its content straight to your clipboard.
What actually comes out clean — and what doesn't
An honest look at which documents extract well and which need a different approach.
| Document type | What to expect | Best output |
|---|---|---|
| Letters & simple reports | Single-column text extracts in the correct reading order reliably. | Text — clean |
| Articles & whitepapers | Flowing paragraph text extracts well; headings and body text stay in order. | Text — clean |
| Multi-column layouts | Content order may not match visual reading order — columns can interleave. | Text — check carefully |
| Tables & spreadsheet-style data | This converter does not reconstruct table columns or guarantee their original reading order. Cells may not line up or appear in the expected sequence. | Text — verify against source |
| Design mockups & brochures | Position is captured approximately; original fonts and fine styling are lost. | HTML — as a starting sketch |
| Scanned or photographed pages | Scanned or image-only PDFs do not contain a selectable text layer. This tool extracts existing PDF text but does not perform OCR. To process scanned pages, use our PDF OCR to Text tool first. | Use PDF OCR to Text first |
What the HTML reconstruction can and can't preserve
Two specific technical limits explain almost everything about how the HTML output looks compared to the source PDF.
Position: close, not exact
Each text span is placed at the x/y coordinates pdf.js reports for it — that part is accurate. The horizontal width of each span, though, is estimated as string length × font height × 0.5, a rough average-character-width guess rather than the real width the PDF specifies. Strings with mostly wide characters (like capital letters) or mostly narrow ones (like "i" and "l") will look stretched or compressed relative to the original.
Fonts: not preserved
pdf.js reports each text item's font as an internal identifier used inside that specific PDF, not a real font family name a browser can use. The CSS font-family declaration in the output will almost always fail to match anything installed, and your browser's default font renders instead. This is the single biggest reason the HTML output doesn't visually match the original PDF.
What it's still useful for
The relative position of text blocks — what's near the top, what's indented, roughly how paragraphs are laid out — comes through reasonably well. It's a fast way to get a rough structural sketch to build from, not a way to reproduce a document's exact appearance.
When to skip HTML entirely
If you just need the words — for editing, searching, repurposing into an article, or pasting into another document — the Text tab gives you exactly that without any of the positioning or font approximation. Use HTML only when position genuinely matters to your next step.
When the output doesn't look right
What's actually happening, and the fastest way through it.
HTML output uses the wrong font
pdf.js reports an internal font identifier, not a real CSS font name, so the browser falls back to its default.
Expected behavior — manually apply the correct font in your own CSS if needed.
Text in the HTML tab looks stretched or squished
Span widths use an estimated average character width, not the PDF's real per-character spacing.
Use the Text tab instead if exact spacing doesn't matter, or adjust the CSS manually for specific spans.
A table or multi-column page reads in the wrong order
Text extracts in the PDF's internal content-stream order, which doesn't always match visual left-to-right, top-to-bottom order.
Manually reorder the extracted text, or check the HTML tab's approximate positions as a reference for the correct order.
Extraction comes back nearly empty
The PDF is likely scanned or image-based, with no embedded text layer for pdf.js to read.
Run the file through PDF OCR to Text first, then paste the extracted text elsewhere.
A password-protected PDF won't load
Some password-protected or encrypted PDFs require a password or may not be supported by the current PDF.js configuration.
If prompted, enter the PDF password. If the file still cannot be processed, try an unlocked copy or another compatible PDF.
Wrong font in HTML output
Why: Internal font ID, not a real font name.
Fix: Expected — apply your own CSS font.
Text looks stretched
Why: Estimated, not real, character width.
Fix: Use Text tab, or adjust CSS manually.
Table/columns wrong order
Why: Content-stream order, not visual order.
Fix: Reorder manually, use HTML tab as reference.
Extraction nearly empty
Why: Scanned PDF, no text layer.
Fix: Run OCR first, then paste text.
Password-protected PDF won't load
Why: Some password-protected or encrypted PDFs require a password or may not be supported by the current PDF.js configuration.
Fix: If prompted, enter the PDF password. If the file still cannot be processed, try an unlocked copy or another compatible PDF.
Getting usable output on the first try
A working order that avoids the most common redo.
Default to the Text tab
Unless you specifically need approximate position information, Text gives you cleaner, more reliable content every time.
Double-check tables and multi-column pages
Reading order isn't guaranteed for these layouts — verify the extracted text against the original before using it.
Treat HTML as a sketch, not a copy
Use it to see roughly how content was laid out, then rebuild the actual styling and fonts yourself.
Check for a scanned PDF first
If extraction comes back nearly empty, the source is probably scanned — run it through OCR before expecting text here.
Copy straight to clipboard for quick reuse
Skip the download step entirely if you're about to paste the content somewhere else right away.
Keep the original PDF
Extraction is one-way — keep the source file in case you need to re-extract with different expectations later.
PDF to HTML FAQs
If something's not covered here, the troubleshooting section above likely has it.
Will the converted HTML look exactly like my PDF?
No. The HTML output positions text using an estimated width for each string, not real font metrics, so spacing can look slightly stretched or compressed. It also does not preserve your PDF's actual fonts — pdf.js reports an internal font identifier, not a usable CSS font name, so the browser's default font is what actually renders. Treat the HTML output as an approximate structural base, not a visual replica.
Which output should I use, HTML or Text?
Text extraction is the reliable one — it pulls every character exactly as pdf.js reads it. Use HTML only when you specifically need position information preserved approximately; for reading, editing, or repurposing content, the Text tab is almost always the better choice.
Will this correctly extract tables or multi-column layouts?
Not reliably. Text is extracted in the order it appears in the PDF's internal content stream, which for multi-column layouts and tables often does not match the visual reading order. Simple single-column documents extract cleanly; tables and columns may come out jumbled.
Does this tool work with scanned PDFs?
Scanned or image-only PDFs do not contain a selectable text layer. This tool extracts existing PDF text but does not perform OCR. To process scanned pages, use our PDF OCR to Text tool first.
What happens to my file after I'm done?
Processing runs in your browser, and this tool does not upload your selected PDF to our conversion server. The extracted results remain in the current page until you replace the file, reset the tool, or leave the page.
The write-up on how this was built
Because text extraction and the HTML positioning approximation both run client-side, I wrote up the implementation — how pdf.js reports each text item's transform matrix, and the real limits of reconstructing layout from that data alone.
How to Build a PDF Text and Layout Extractor with pdf.js
Covers pdf.js's getTextContent API, transform matrices for positioning, and why font names and reading order are the two hardest things to reconstruct from text alone.