Updated

How to convert a webpage to Markdown

Converting a webpage to Markdown means keeping the article and dropping the rest of the site. You want the headings, paragraphs, lists, tables, links, and code. You do not want the navigation bar, the cookie banner, the related-post rail, or the scripts that made the page interactive. WebInk does that job in a Chrome extension and in tools on this site: paste a public URL, or paste HTML you already copied.

This guide is the practical version. It covers when to use the URL to Markdown tool, when to use the extension, what a careful conversion keeps, and where to go if you want to send the result to ChatGPT, save a file, or call the developer API.

On this page

What the conversion changes

A browser page is HTML. Headings are heading elements, links are anchors, and code sits in pre and code. Markdown is a smaller plain-text syntax for the same structure. A heading becomes a line that starts with #. A link becomes [label](url). A fenced code block can keep a language tag when the page provided one.

The useful part is not the syntax trivia. Notes apps, Git repositories, and most chat models already expect Markdown. Paste a rendered page and you often lose heading levels. Paste raw HTML and you keep every class name. A conversion sits between those two failures: structure stays, chrome goes.

The extension path runs four steps. A readability pass (Defuddle) pulls the main article out of the live document. A Turndown converter turns that HTML into Markdown, using the heading, list, and fence options you set. An optional template wraps the body with front matter or a prompt. An optional Prettier pass formats the text. The public API uses a separate converter on the server. Treat the two as related, not identical, if a pipeline depends on an exact fence style. Compare one page before you lock a diff around either output.

Reader mode in the browser is a cousin of this job, and it is not the same deliverable. Reader mode hides chrome while you read. It does not hand you a file, a template, or a prompt. When the destination is Obsidian, a pull request, or a chat box, you need the text. That is the conversion.

Which path can see the page

There are two different fetches. Mixing them up is the usual reason a conversion looks empty.

Public URL. Open URL to Markdown, paste an https link, and convert. The server fetches that URL. It can read a blog post, a docs page, or a news article that an anonymous visitor can open. It cannot see your cookies. A paywall, a login wall, or a page that renders only after client-side JavaScript may come back as a shell. The tool is the right first stop when you have a link and you are not signed in on that site.

Open tab. Install the Chrome extension and run it on the tab you are already reading. Conversion uses the document in that tab, so it includes content you reached by logging in. Use it for dashboards, member posts, internal wikis, and heavy single-page apps that look blank to a simple HTTP fetch.

HTML you already have. If the source is a snippet on your clipboard, use HTML to Markdown instead of pretending it is a URL. That tool does not fetch anything. It converts the fragment you paste.

Do not crawl a whole site through either tool. WebInk converts one page, or one API request, at a time. A pile of tabs is still a pile of single conversions. Work down the list. There is no multi-URL zip in WebInk, and inventing one with a loop against the public API is a good way to hit rate limits and to archive pages you did not mean to store.

Convert a public URL

  1. Copy the canonical article URL. Prefer the short article path over a tracking link full of query parameters. Query strings sometimes hold session tokens. Do not send those to a converter, and do not paste them onward into a chat box.
  2. Open the URL to Markdown tool and paste the link. Submit one article URL, not a homepage, unless the homepage is the document you wanted.
  3. Read the preview. The title should match the article. The first heading should be the real title, not the site name. Code samples should be fenced, not flattened into one paragraph. Tables should still have their columns.
  4. Copy the Markdown, download the .md file, or send it to an assistant. Download names on the web tool are slugified from the title: lowercase, punctuation folded to hyphens, trimmed to a short name. The extension uses a different filename rule, described in the save guide.

If the preview is a login form or a cookie notice, the fetch did not see the article. Switch to the extension on a tab where you can already read the piece. Fetching harder will not create cookies the server does not have.

Convert the tab you have open

  1. Pin WebInk and open the side panel on the article tab. The panel converts the document that Chrome has loaded, including content behind a login you already passed.
  2. Let the panel finish. If images are missing, scroll the original page to the bottom and convert again. Images that load only when you reach them are not in the document until the browser has requested them.
  3. Skim the Markdown tab. Heading levels should follow the article, not the site header. Links should still point at the original destinations. A copy button glued onto a code sample by the docs theme should not become a paragraph in the middle of the function.
  4. Copy, download a single .md file, apply a template, export a ZIP, or continue to Send to AI. Single-file download is part of core conversion and does not require Premium. ZIP export with images does not require Premium either.

Single-file download in the extension starts from the page title. Spaces become underscores, characters that are unsafe in filenames are removed, and the name ends in .md. If the title is empty after that cleanup, the file is converted_content.md.

What a good conversion keeps

Expect these to survive when the page used ordinary HTML:

  • Heading hierarchy, from the article rather than the site chrome
  • Paragraphs, emphasis, and lists
  • Links, including their targets
  • Tables
  • Fenced code blocks
  • Block quotes
  • Images as Markdown image syntax, still pointing at the original URL until you export a ZIP

Expect these to disappear, because they are not the article:

  • Global navigation, footers, and share bars
  • Most ads and sidebars
  • Script and style tags
  • Cookie banners, when the extractor can tell them apart from the body

Some pages still need a human pass. Comment threads, infinite “read more” blocks, and math that exists only as a canvas are common leftovers. Text formulas and MathML have a better chance than a screenshot of an equation. If a docs site splits one topic across tabs that are not in the initial HTML, open each tab and convert it. One click cannot see a panel the page has not rendered.

A docs paragraph plus a fenced sample is the pattern you are protecting. In the browser you see a heading, a sentence, and a code block with a copy button supplied by the theme. After conversion you want the heading, the sentence, and the fence. You do not want the copy-button label, the “on this page” box, or the footer legal line in the middle of the function. If those show up, the extractor grabbed too much. If the function disappeared, it grabbed too little.

Templates, when the body is not the file

The Markdown body is the article. Many workflows want a file, not only a body: YAML front matter for a vault, a source URL so you can find the page again, or a short instruction in front of the text before it goes to a model.

Templates are Mustache-style wrappers. Variables include {{title}}, {{url}}, {{markdown}}, {{toc}}, {{publishedTime}}, {{excerpt}}, {{byline}}, and {{siteName}} when the page provided them. Quote the title field when titles contain colons. The templates feature shows the editor. The extension can keep more than one template and switch from the toolbar. The API accepts a template field as well. Read the developer docs for the request shape, and do not assume the API and the extension emit the same bytes for every tag.

---
title: "{{title}}"
source: {{url}}
date: {{publishedTime}}
---

{{markdown}}

Save, package, or hand off

Copy is enough when the destination is already open. Download a single .md file when you want a file and you can live with remote image URLs. Choose ZIP export when the note has to open offline. WebInk builds a zip from the page title, writes the Markdown inside it, downloads referenced images into an images/ folder, and rewrites successful image links to that folder. Data-URL images are left out of that download. If an image fails, the original URL stays in the Markdown, so you do not get a relative path to a missing file. ZIP export does not require a subscription. The steps live in the save guide and on the ZIP export page.

Sending the same Markdown to a model is a different job from saving it. Chat products cap the query string, and Gemini on the web tool does not take the prompt on the URL. Read send a webpage to ChatGPT before you assume one click always prefills a long article. The extension screen is Send to AI. If you are choosing Markdown because of tokens rather than because of files, the HTML versus Markdown note explains the tradeoff. The numbers on that page are examples. WebInk does not show a live token meter.

Check the result before you trust it

Run this list on the first page from a new site. After that, spot-check. The second page from the same template is usually faster. A page from a different site is the real test.

  • The title in the output is the article title.
  • The opening paragraph is the article, not a menu.
  • Heading levels do not jump because a sidebar used a deep heading.
  • A code sample is inside a fence, and indentation survived.
  • A table still has the same column count.
  • Links are not rewritten to the site homepage.
  • You did not leave a tracking parameter or a signed URL in a file you are about to commit or paste into a shared chat.

For research notes, keep the source URL in the template so a later summary can be checked against the page. The AI research use case describes that habit. For a vault, read the Obsidian use case before you assume WebInk writes the note for you. It does not. For a script, start at the developer use case.

Limits

WebInk is a converter. It is not a browser automation tool and it is not a site crawler. One URL in the tool, one tab in the extension, one request on the API.

Private network addresses are blocked on the server fetch. That is deliberate. Do not point the URL tool at localhost or an intranet address and expect a document back. Open that page in Chrome and use the extension, which reads the tab you already loaded.

Very large pages can succeed as files and still fail as chat prefills, because assistants cap the query string. Download or copy in that case. The web tool copies the prompt and opens the assistant when the link would be longer than 8,000 characters.

Pages that are only a video player, a PDF viewer, or a canvas app will not become a good article. Start from a webpage or from HTML. If you need a native Obsidian note with highlights, use Obsidian Web Clipper. WebInk’s comparison is on the Obsidian Web Clipper alternative page. If you are leaving MarkDownload, the matching note is the MarkDownload alternative page.

Convert one representative page from your own reading list before you rebuild a workflow. Fix the template, the filename, and the destination on that page. Then do the next one.

Open URL to Markdown

More from WebInk