VoriTools

Fetch Webpage Content

Submit the page URL to fetch its content. The editor displays the returned HTML; results depend on what the remote site allows access to.

How to fetch a page into the editor

This page asks the VoriTools server to request a web address and puts the HTML that comes back into an editor. It is a fetch-and-edit tool, not an article reader: what you see is the response source, with no readability pass and no text extraction.

The request is made by the server, so the target site sees VoriTools rather than your browser. Cookies, logins and client-side state from your own session are not sent, and pages that require them will come back as a login screen or not at all.

  1. Paste the full address of a publicly reachable page, including http:// or https://, into the field above the button.
  2. Press Fetch page. The VoriTools server makes the request; the tool follows up to five redirects and gives up after 30 seconds.
  3. Wait for the response. When it arrives, the returned HTML fills the editor; the address field keeps the URL you submitted so you can fetch it again.
  4. Review or edit the content with the toolbar, which is labelled in the language of this page. Scripts and inline event handlers in the fetched page are removed by the editor filter before anything is displayed.
  5. Select and copy what you need, then submit another address to replace it. Failures are reported in a notice above the form instead of leaving the editor silently empty.

What the fetch does, and where it stops

A server-side request, not a browser visit

The request leaves from the VoriTools server, which is why this page can show source from a URL your own network might not reach. Private, loopback, link-local and cloud metadata addresses are refused before a connection is attempted, so addresses such as 127.0.0.1 or 169.254.169.254 return an explanation instead of content.

Nothing from your browser session travels with the request: no cookies, no login, no referrer of yours. The target site decides how to answer, and many large sites answer automated requests with a consent page, a challenge or a block rather than the article.

What the editor actually shows

The editor holds the response body as HTML, so markup, alt attributes and inline styling survive while the page becomes editable. The editor filter removes scripts and inline event handlers, which is what keeps a fetched page from running code in your session, and the HTML source view shows the filtered result.

Links and images in the fetched page keep their original addresses. Absolute URLs still point at the source site, while relative ones resolve against this page and usually break; a document that depends on relative assets will look incomplete even though the HTML itself arrived intact.

When a fetch comes back empty

A response that is not text — an image, a PDF, a font or a download — cannot be shown here and leaves the editor empty with a notice. A timeout, a name that does not resolve, an HTTP error status and an empty body are reported separately, so the reason for a failure stays readable.

Pages that build themselves in JavaScript return their shell markup rather than their rendered content, because the fetch does not run scripts. For the same reason a page behind a login or an anti-bot check returns what an anonymous visitor would receive. The editor shows a snapshot of one response, not a live view of the site.

Recent tools: