# Scanned PDF to HTML: When a Web Page Is the Right Output

- Author: Schema Law (https://www.schemalaw.com/)
- Published: 2025-09-02T08:16:02Z
- Updated: 2026-10-11T19:22:20Z
- Category: Converting scans
- Canonical: https://www.schemalaw.com/blog/scanned-pdf-to-html

> When to convert a scanned PDF to HTML, what the HTML file contains, and how to email, print, save and read it without losing track of the source pages.

Convert a scanned PDF to HTML when the document will be read on a screen and not edited or filed: in a browser, in the body of an email, on a phone or on an internal page. The HTML file holds the recognized text and tables as tagged content, and any web browser opens it.

HTML is the format of web pages, and it is also a way to hand someone a document. It has two properties the other targets lack. Every computer and phone already has a program that displays it, and the text fits itself to whatever width the reader has. It also has one large drawback, which is that the page of the original stops being the unit. This guide covers the uses, the handling and the drawback.

## What is inside an HTML file made from a scanned PDF?

An HTML file made from a scanned PDF contains the words OCR read from the pages, wrapped in tags that say what each piece is: a heading, a paragraph, a list, a table with rows and cells. It contains no pictures of the pages. What you see in the browser is text drawn fresh from those tags.

Open the file in a plain text editor and a scanned lease looks something like this:

```
<h1>COMMERCIAL LEASE AGREEMENT</h1>
<p>This Lease is entered into as of March 3, 2021, by and between
Harlow Properties LLC and Dunmore Freight, Inc.</p>
<h2>3. BASE RENT</h2>
<table>
  <tr><th>Lease year</th><th>Monthly rent</th></tr>
  <tr><td>1</td><td>$18,450.00</td></tr>
  <tr><td>2</td><td>$19,003.50</td></tr>
</table>
```

The parties and figures are fictional. The tags in angle brackets never appear on screen. The browser uses them to decide that the first line is large and bold, that the next block is a paragraph, and that the last block is a grid.

### What the file does not contain

- **The scan itself.** No page images, so no letterhead, no logo and no margins as they were on paper.
- **Signatures, initials, stamps and seals.** These are pictures on the page. In the HTML they are absent, or appear as whatever stray characters recognition made of them.
- **The original fonts and spacing.** The browser chooses the type from the file's styling or its own defaults.
- **Handwritten notes in the margin,** unless recognition read them as text, in which case they appear inline with nothing to show they were handwritten.
- **Any measure of doubt.** A misread word looks exactly like a correct one.

So an HTML conversion is a reading copy of the document's content. It is not a likeness of the document.

### The shape of a Schema Law HTML export

Schema Law lists HTML among its eight export formats and describes it on the homepage as "One web page, with a section for each source page". A fuller description of the tags in that file is in the Markdown guide, in the section on [converting a scanned document to HTML for an intranet page](https://www.schemalaw.com/blog/pdf-to-markdown-ocr#converting-a-scanned-document-to-html-for-an-intranet-page). Every plan includes the HTML export, the free one too; the [pricing page](https://www.schemalaw.com/pricing) lists how many pages each plan lets you convert.

## When is HTML a better target for a scan than Word or PDF?

HTML is the better target when the reader only needs to read the content, on whatever device they have, and nobody needs to edit it, file it or see the page as it looked. Word is for editing. A searchable PDF is for keeping the page image with its text. HTML is for showing the content.

| What you need to do | Better target | Why |
| --- | --- | --- |
| Paste the document's text and tables into an email body | HTML | Tables arrive as tables |
| Let a client read a long document on a phone | HTML | Text refits to a narrow screen |
| Put a policy or precedent on an internal page | HTML | It is already the web's format |
| Paste into a web-based editor, wiki or ticket | HTML | Headings and tables carry over from the browser view |
| Redraft the document | Word | Built for editing and tracked changes |
| File with a court or produce in discovery | PDF, as the rules require | The page image is the record |
| Cite by page and line | Searchable PDF | Pages and lines stay where they were |
| Show a signature or a stamp | PDF | Only the image has it |
| Compare two versions line by line | Plain text | No tags in the way |

### Questions that settle it

1. **Will anyone change the words?** If yes, choose Word.
2. **Does anyone need to see the page as it was?** If yes, choose a searchable PDF.
3. **Will it be cited by page?** If yes, PDF, or HTML read alongside the PDF.
4. **Is it going into a screen that is not a document program?** If yes, HTML.

You do not have to pick only one. One upload can be exported in several formats, so the searchable PDF can go in the matter file while the HTML goes to the people who need to read it.

### Where HTML is the wrong answer

Do not send HTML where a rule or a recipient specifies a format. A filing follows the court's or agency's own requirements, and a production follows whatever was agreed or ordered. Check those before choosing. The post on legal document conversion covers [choosing a format by who receives the converted file](https://www.schemalaw.com/blog/legal-document-conversion#choosing-a-format-by-who-receives-the-converted-file).

HTML is also not what is meant by a request for an accessible PDF. That is a PDF with tags of its own, and the guide on [how to make a PDF readable](https://www.schemalaw.com/blog/how-to-make-pdf-readable) explains it.

If the choice is among the three text-based exports, see the comparison of [Markdown versus HTML versus plain text exports](https://www.schemalaw.com/blog/pdf-to-markdown-ocr#markdown-versus-html-versus-plain-text-exports).

## Pasting a converted scan into an email with its tables intact

To put a converted scan in an email with its tables intact, open the HTML file in a browser, select the part you want, copy it, and paste it into a message that is set to rich formatting. The browser places the table on the clipboard as a table, and the mail program receives rows and cells.

This is the use HTML is best at. Copy the same table from a scanned PDF's text layer and you get figures strung out in lines. Copy it from the browser and the grid comes with it.

### The steps

1. Export HTML and open the file in a browser.
2. Check the passage against the scan first. Whatever you paste will be read as the document's words.
3. Drag to select the heading, paragraphs and table you need. For a whole table, start just before it and end just after.
4. Copy.
5. In your mail program, confirm the message is in its rich or HTML format, not plain text. In a plain text message the table collapses.
6. Paste with the ordinary paste command. A "paste as plain text" command removes the table.
7. Look at the result. Adjust column widths if the mail program allows it.
8. Send the message to yourself before sending it to anyone else, and open it on a phone as well as a computer.

### What changes on the way

Mail programs each apply their own handling to pasted content, and the recipient's program applies its own again. Expect the words and the grid to survive. Do not count on fonts, shading, border weight or column widths arriving as you saw them. That is why step 8 exists. If the table matters and looks wrong at the other end, attach the PDF as well.

When you paste a coverage table into a client email, keep the policy limit, the deductible and any exclusion in their own cells. The insurer name and the claim number belong in the heading you copied. Check those words against the scan before you send. A deductible or an exclusion in the wrong cell will travel with the email.

### Wide tables

A table with ten columns does not fit a message window. Three options: paste only the columns the reader needs, put the table in an attached spreadsheet and summarise it in the message, or turn the table so that its fields run down the side.

### Say what the text is

Add a line over the pasted passage: "Text converted from the scanned lease dated March 3, 2021 (attached). Check the attachment for the exact wording." The recipient then knows that the message body is a convenience and the attachment is the document.

### When formatting is not wanted

Some destinations want words only: a case note, a form field, a message in a system that strips formatting. For those, start from plain text and skip the cleanup. The guide to [scan to text](https://www.schemalaw.com/blog/scan-to-text) covers pasting recognized text into places like that.

The usual duties about what you send to whom apply to pasted text exactly as they do to an attachment. Pasting a passage into a message body does not make it less confidential.

## Opening, printing and saving an exported HTML file

An exported HTML file opens in a web browser when you double-click it. It is a file on your computer, not a page on the internet, even though it appears in a browser tab. You can print it, save it as a PDF from the print dialog, rename it and store it with the matter like any other file.

### Opening

Double-click the file, or drag it onto a browser window. The address bar shows a path that starts with `file:` and names a folder on your machine. Nobody else can open that address. To share the document you send the file, not the address.

If double-clicking opens a text editor or Word instead, right-click the file and choose a browser from the "open with" list. Word can open HTML files, and will show the content as an editable document, but if editing is the goal a Word export is the cleaner start.

### Checking that the file stands alone

Some HTML files pull fonts, styles or images from the internet when opened. To see whether yours does, disconnect from the network and open it. If it looks the same, everything it needs is inside the file, and it does not depend on a connection on the recipient's machine either.

### Printing

Use the browser's print command. Three things to know:

- **The browser sets the page breaks.** They fall wherever the paper runs out, not where the source pages ended.
- **The browser adds its own header and footer.** By default these can include the file path, the date and a page count. Turn them off in the print dialog if you do not want a folder path printed on a document.
- **Tables can split across sheets.** Look at the preview before printing a long one.

### Saving as PDF

Choosing "Save as PDF" in the print dialog produces a PDF with real, selectable text. Be clear about what that file is. It is a new document generated from recognized text, with new pagination. It is not the scan and should never be filed or named as if it were. Put "converted text" in its file name.

### Naming and storing

Keep the HTML file beside the scan it came from, with a name that ties the two together, for example `HARLOW-0004127 lease - converted text.html` next to `HARLOW-0004127 lease.pdf`. Browsers save downloads to a general downloads folder unless told otherwise, so move the file into the matter's folder when you download it.

### Editing

A plain text editor shows the tags and lets you change the words between them. That is fine for correcting a misread word before you send the file. For anything more than that, convert to Word.

## Does a scanned document read well on a phone once it is HTML?

Yes, in the sense that matters: the text is real text, so the phone's browser can wrap each line to the width of the screen. A scanned PDF on a phone shows a shrunken picture of a letter-size page that has to be zoomed and dragged. How well a given HTML file fits is something to test.

### Why HTML can fit and a scan cannot

A scanned page is an image with fixed proportions. Make it narrow enough for a phone and the type is too small to read; enlarge the type and the line runs off the screen. HTML has no fixed line length. The browser breaks each paragraph wherever the screen ends, at any text size.

### What to test

Send the file to your own phone and open it before you send it to a client.

- **Does the text fill the width at a readable size?** Some HTML files open on a phone as a miniature of a desktop page and need zooming, depending on how the file was written. If yours does, try the browser's reader view, which re-flows the main text.
- **What do tables do?** A wide table either squeezes its columns until words break mid-line or runs off the side of the screen. Turning the phone sideways helps with tables of moderate width.
- **How does the file open?** Tapping an HTML attachment may show a preview inside the mail app, open the browser, or do nothing useful, depending on the phone and the app. Find out which before you tell a client to "just tap the attachment".
- **Is it too long to scroll?** A 60-page agreement is a very long single page on a phone. The browser's find-on-page command is the way around it, so tell the reader it exists.

### When the phone reader needs the page image anyway

A client who must check a signature, read a handwritten note or see a stamp needs the PDF. Send both and say which is which: the HTML for reading, the PDF for what the paper looks like.

### A sensible covering note

"The attached .html file is the text of the agreement, converted from the scan so that it is easier to read on a phone. It may contain conversion errors. The attached PDF is the scanned document itself and is the copy to rely on."

## Page numbers and page breaks that an HTML export leaves behind

HTML has no pages. An export is one continuous document, so the original page breaks, the printed page numbers and any line numbers exist only if the export writes them into the text. For citation that is the format's main cost: cite from the scan, and use the HTML to find the passage.

### What is lost

| On the paper | In an HTML file |
| --- | --- |
| Page breaks | Gone, unless the export marks where each source page begins |
| Printed page numbers in the header or footer | Become ordinary lines of text in the flow, or are dropped |
| Running headers and footers | Repeat as stray paragraphs between sections of text, if kept |
| Line numbers on a transcript | Become numbers mixed into the text, or a column of their own |
| Footnotes at the foot of a page | Land wherever the page's text ends, mid-document |
| A sentence that crosses a page break | May be split in two by a page marker |
| "Page 4 of 12" | Meaningless once there are no pages |

### What a per-page export keeps

An export that gives each source page its own section, as the Schema Law homepage says its HTML does, keeps one thing: you can tell which page of the uploaded file a passage came from. That is the file's page count. It is not necessarily the number printed on the paper, and it is not a Bates number. A document with a cover sheet and a roman-numbered contents page will have its printed page 1 several pages into the file. The post on [PDF page numbers that do not match](https://www.schemalaw.com/blog/pdf-page-numbers-dont-match) explains the three numbering systems and which to cite.

### Printing makes new page numbers

Print the HTML and the browser paginates it afresh. Page 7 of that printout has no relation to page 7 of the original. If a printed copy of the converted text goes into a file, mark it on its face as converted text so that nobody cites its page numbers.

### A check before you quote from HTML

1. Find the passage in the HTML.
2. Note which source page section it sits in.
3. Open the scan at that page.
4. Read the passage on the page image and correct your quotation to match it.
5. Take the page number, and the line number if there is one, from the image.
6. Cite the scan.

### Sentences split at a page boundary

Where a sentence runs from one page to the next, a per-page export shows the first half at the end of one section and the second half at the start of the following one, perhaps with a footer line or page label between them. Read across the boundary before you copy a passage that sits near one, and remove anything that belongs to the page furniture and not to the sentence.

Used with those limits in mind, HTML is a good reading copy and a poor record copy. Keep the scan as the record, and see the [formats list on the homepage](https://www.schemalaw.com/#formats) for the other exports that one upload can produce.

## Try it on a real document

Upload a scanned PDF and export it as Word, a searchable PDF or plain text on the free plan. Your documents are never used to train an AI model. [Start free](https://www.schemalaw.com/api/auth/google)
