How to Extract HTML From a Website: Raw Markup, Text, and One-Page Checks

Choose the output before you extract

“Extract HTML” can describe several different jobs. The right output depends on what you will do next. If you are checking a canonical URL or a JSON-LD block, you need markup and attributes. If you are preparing a manual content review, readable text is more useful. If you are debugging a visible component, you may need to compare the response with the browser's live DOM instead of extracting either view alone.

• Complete source: preserve tags, attributes, scripts, metadata, and nearby context.
• Readable text: remove presentation and executable markup so a person can review the document's words.
• Focused element: locate a specific H1, link, image, canonical, or meta element and inspect its value in context.
• Rendered DOM: inspect the browser after parsing and runtime changes when the visible page does not match the response.

Use URL mode or pasted HTML mode

There are two useful starting points. URL mode retrieves the HTML available from a public webpage, so the result can be affected by redirects, request conditions, blocking, and the site's response. Pasted-HTML mode analyzes the exact text you supply and does not need to fetch a live page. The two modes answer different questions; neither one recreates a private, authenticated, or JavaScript-rendered application automatically.

• Choose URL mode when you need to inspect the HTML currently returned for a public deployed page.
• Choose pasted HTML mode when you have a saved file, draft, fragment, or response you are allowed to review.
• Keep the input unchanged before editing or filtering it. The original makes a later conclusion auditable.
• If you need to see how supplied markup renders, use HTML Viewer after extraction; a text view and a visual preview serve different purposes.

Follow a one-document extraction workflow

A narrow workflow is easier to repeat than an unbounded scrape. Start with one document and one question, then move to a focused checker only when the evidence says you need it.

• Name the target: for example, “Does the returned page contain the product description?” or “What readable text is in this saved HTML?”
• Enter the complete public URL, or paste the HTML you are authorized to inspect.
• Run HTML Extractor and choose the text view when your task is about readable words.
• Keep the source view available. If a sentence, link, or count looks surprising, return to the original markup around it.
• Record the input, date, mode, and conclusion. A later response may not be identical.
• Use View Source or a focused checker when your question depends on tags, attributes, metadata, or response context rather than text alone.

What SolViewer's text view keeps and removes

SolViewer's text view is designed to make one document easier to read. It preserves text from common content elements such as headings, paragraphs, lists, and tables, then adds line breaks around block-level elements. It removes elements that normally represent code, styling, embedded content, or executable behavior, including script, style, noscript, svg, iframe, object, and embed.

That filtering is useful for a text review, but it changes the output by design. A text view is not a lossless copy of the HTML and does not create a link inventory, image inventory, metadata report, or structured-data validation. Use the complete source when the removed markup is part of the question.

<article>\n  <h1>Spring menu</h1>\n  <p>Reserve a table for the new menu.</p>\n  <img src='menu.jpg' alt='Seasonal menu'>\n  <script>trackView()</script>\n</article>\n\nReadable text\n\nSpring menu\nReserve a table for the new menu.

The illustrative output keeps the heading and paragraph, but not the image URL or script body. If you need to check the image's src, alt, or surrounding link, inspect the source instead.

Read an element in source context

HTML is a document language, not just a bag of visible words. The WHATWG HTML Living Standard defines the roles of elements and attributes. A text extraction can tell you that “Book a table” appears, but only the source can show whether it is inside an anchor, what its href is, or whether a visible-looking value sits inside a template or script.

<h1>Spring menu</h1>\n<a href='/book'>Book a table</a>\n<img src='menu.jpg' alt='Seasonal menu'>

• The H1 supplies the page's main heading in this fragment.
• The anchor supplies a relative destination, but this fragment does not prove that the destination resolves.
• The image supplies an alternative-text value, but the fragment does not prove that the image loads or that the description is appropriate.
• The source shows relationships and attributes that a plain text view intentionally leaves out.

Keep returned HTML separate from the rendered page

The browser's Document Object Model is a live representation that scripts can change after the response is parsed. MDN's DOM overview describes the DOM as an interface for representing and interacting with a document. If a page loads its main content from an API, a source-based extraction can be accurate while still missing what a user sees after the request finishes.

• Visible text absent from source may be inserted after load, revealed after interaction, or available only for a particular session.
• Text present in source but absent from the screen may be hidden, replaced, or affected by CSS and runtime state.
• A frame or external application may contain content that is not part of the document you extracted.
• A redirect, cookie, device, language, or bot-protection response may mean you did not receive the same document as another visitor.

When the two views disagree, write the distinction explicitly: “present in the returned HTML,” “present in the current DOM,” or “not observed in this response.” Do not collapse those statements into “the page has no content.”

Diagnose common extraction surprises

The extracted text is shorter than the visible page

First compare the returned source with the live DOM. Content added by JavaScript, content behind a frame, and session-dependent content can be outside a source-only result. If the missing words are in the source but not the text view, check whether they were inside an element intentionally removed from the text output.

The output includes words you did not expect

Read the source around the phrase. It may come from an accessibility label, a hidden template, a fallback message, navigation, or an element that is not part of the article's main reading flow. Text presence alone does not tell you how a user encounters it.

A link or metadata value is missing

That is expected when the task uses the text view. Switch to View Source and inspect the relevant element and attribute. Use Heading Checker for an H1-H6 outline, or a focused metadata tool when the question is narrower.

Know the scope of a one-page extractor

Extracting one document does not crawl a website, follow every internal link, compare every template, or build a complete content inventory. It also does not reveal backend code, private data, access-control rules, or a search engine's indexing state. Those questions need different evidence and, in some cases, permission to inspect the application or its analytics.

• Need complete markup and nearby tags? Use View Source.
• Need to preview supplied markup? Use HTML Viewer.
• Need a heading outline? Use Heading Checker.
• Need a broader page-level review? Use SEO Checker, then verify important findings in the deployed page and external tools.

Frequently asked questions

Does an HTML extractor show the complete source?

The Source view can show the retrieved or pasted HTML, while the Text view contains readable text after intentional filtering. Use View Source when tags, attributes, scripts, metadata, or structured data matter.

Can it extract content generated by JavaScript?

Not from a source-only response. The extractor processes returned or pasted HTML and does not render the page or execute its JavaScript. Compare the response with the live DOM when the visible page depends on runtime code.

Can I extract every link from an entire website?

No. This workflow is for one document. A site-wide link inventory requires a crawler, an explicit scope, and checks for redirects, duplicates, permissions, and request load.

Why does the text view not show image URLs?

Image URLs are attributes in markup rather than readable text. Open the source and inspect the relevant img element when you need its src, srcset, alt, or surrounding link.

Is extracted text automatically an SEO audit?

No. The text view helps you read one document. It does not judge search intent, content quality, rendering, indexation, performance, or the complete set of page-level signals. Use it as evidence for a focused review, not as a standalone verdict.

Sources

• WHATWG HTML Living Standard — element meaning, attributes, and document processing.
• MDN Web Docs: Document Object Model — the live document interface that scripts can modify after parsing.