Updated November 9, 2026

HTML vs Markdown for LLMs

Models do not read your screen. They read the text you send. Full page HTML includes navigation, class names, inline styles, and often the scripts that built the page. Markdown keeps a heading as a heading and drops most of that chrome. For a prompt, a note, or a docs diff, Markdown is usually the smaller and clearer input. HTML still wins when the task is the document object itself.

WebInk does not show a live token estimate. The table below is an illustration of one imaginary article, so you can see the shape of the tradeoff. It is not a measurement of a page you paste tomorrow, and it is not a quote from a model vendor.

Example sizes for one long article

Picture a public essay of about 1,800 words, with a few headings, one table, two code samples, and a handful of images referenced by URL. The character counts below are round examples. The token column uses a common English rule of thumb: about four characters per token. Real tokenizers split words, punctuation, and code differently. Treat every number in this section as an example.

On these example rows, Markdown is a bit under a tenth of the full page and a bit over a third of the article HTML. The gap comes from tags and from chrome, not from a magical compression of the prose. The words of the essay are still there.

An example cost, not a price list

Suppose a model billed $2.50 per million input tokens. That figure is illustrative third-party pricing, a round example so the arithmetic is visible. It is not WebInk’s price, and it is not a current vendor quote. Check the model you actually call.

• Full page HTML, 30,000 example tokens: about 7.5 cents of input.
• Article HTML, 6,000 example tokens: about 1.5 cents of input.
• Markdown, 2,250 example tokens: a bit over half a cent of input.

Output tokens, caching, and retries are not in those figures. A long answer can cost more than the article you sent. The reason to prefer Markdown is still real: you spend the context window on the essay, and you leave less room for the model to quote a menu.

When HTML is the right input

Keep HTML, or skip both formats and use a browser, when the question is about the page as a document:

• You need element structure, ARIA attributes, or class hooks.
• A browser agent must click, type, or read content that never becomes text.
• The “article” is a web app. Markdown of an empty shell is not the dashboard you see after login. The extension can convert the rendered tab. The URL tool may only see the shell.

Code-heavy pages shrink less. A fenced sample is close to the original pre text. The savings are the tags around it, not the sample. Wide tables can get longer in Markdown than in compact HTML, because each cell repeats its separators. A page that is mostly a giant table will not match the essay in the table above.

Images do not shrink just because the surrounding text became Markdown. An image link is a short URL. Asking a vision model to look at the image is a separate request, and a base64 blob inside HTML is large on purpose. ZIP export saves image files next to the note. It does not tokenize them.

When Markdown is the right input

Use Markdown when a person or a model needs the writing:

• A prompt to ChatGPT, Claude, Gemini, or another assistant.
• A note in Obsidian or a page you will paste into Notion.
• A file in Git, where a diff of prose should be readable.
• A documentation pipeline that already speaks headings and fences.

WebInk’s job on that list is the conversion. The webpage to Markdown guide chooses between the public URL tool and the extension. The send guide covers prefilled chats versus copying the prompt. The developer API returns JSON or text/markdown for a public URL. None of those surfaces display the example token counts from this page.

If you only remember one line: send Markdown of the article when you want the model to read the article. Send HTML when you want something to inspect the markup. Do not send both and hope the extra tokens help.

The same sentence, three ways

The table above is about bulk. This fragment is about what the model actually has to parse. All three say that writers delete a cache key on update. Only one of them is a heading plus a sentence.

Full-page fragment (illustrative):
<nav class="site-nav">Home · Pricing · Login</nav>
<article class="post prose">
  <h2 id="what-changed">What changed</h2>
  <p>Writers delete the key on update.</p>
</article>

Article HTML:
<h2 id="what-changed">What changed</h2>
<p>Writers delete the key on update.</p>

Markdown:
## What changed

Writers delete the key on update.

On a real site that menu, the footer, and embedded JSON repeat on every URL. Markdown keeps the heading and drops the tags around it.

What WebInk puts in the prompt

The URL to Markdown tool fetches a public page through the API and then sends a short instruction plus the Markdown. The HTML tool converts a paste in the browser, strips script and style tags, and sends its own short instruction plus the Markdown. Neither tool sends the raw page HTML to the assistant. The send guide records the wrappers and the 8,000 character URL cap.

The extension reads the open page, extracts the article, converts that HTML with WebInk’s Markdown rules, applies your template, and can format the result unless you turn formatting off. Until transform options are saved, headings are ATX, bullets are hyphens, code is fenced with backticks, and emphasis uses asterisks. The options form’s suggested plus bullets and underscore italics are stored only after you save that form. A prompt that changes after a settings save is often that switch, not a new article.

The extension also removes a leading # title line from the body, because templates can print {{title}} themselves. The Default template is only {{markdown}}, so a file can omit the visible title until you pick a template that adds it. That changes the prompt by a heading, not by the tens of thousands of tokens in the example table. It does change whether the model sees the title as a heading or only inside a front matter field.

The public API uses a separate converter from the extension. Pin one path before you hash output. The developers use case records that split.

A decision you can make in one minute

1. If the question is about the writing, convert and send Markdown. Use the extension when the page is behind your login, and the URL tool when an anonymous fetch can see it.
2. If the question is about markup, send a trimmed HTML fragment you copied on purpose. Keep it to the element you mean. A full document source recreates the top row of the example table.
3. If the question needs a click, a hover, or a canvas, stop using either text format. A browser agent is a different tool. WebInk does not drive the page.
4. If you are comparing cost, rerun the arithmetic with your vendor’s current input rate. Keep this page’s $2.50 per million tokens in the “example only” column. Output tokens, retries, and cached prefixes are outside the sketch.

WebInk does not show a live token count for the URL you paste. Read the preview for a related-links rail before you trust the size. The conversion guide is that checklist, and the save guide is how you keep the file you sent.

FAQ