What is TinyFetch? A Free Web Scraping API

Imagine an assistant that has found the pricing page for a software product. The next job is not to search again. It needs to open that page, retrieve the information on it, and give the application something useful to work with.

That sounds simple until the page depends on JavaScript, contains thousands of words of navigation and boilerplate, or returns technically valid content that tells the model almost nothing.

TinyFetch is TinyFish’s web fetch API for AI agents and applications. Give it a URL and it retrieves the webpage, renders it when needed, and returns clean content as Markdown, HTML, or JSON.

This guide explains how TinyFetch works, what it returns, and when to use it instead of TinySearch, TinyAgent, or TinyBrowser.

What is TinyFetch?

TinyFetch is the retrieval layer of the TinyFish platform. It is designed for workflows that already know which webpage they need to read.

An application sends TinyFetch one or more URLs. TinyFetch retrieves the pages, renders JavaScript-heavy content when needed, extracts useful page content, and returns it in the requested format. Markdown is the default, with HTML and JSON available for workflows that need different representations of the page.

The important distinction is:

TinyFetch starts with a URL.

If your application does not know which page it needs yet, that is a search problem. TinySearch can find relevant sources first. Once the URL is known, TinyFetch can retrieve the page content.

What Web Retrieval Problems Does TinyFetch Solve?

Getting a webpage and getting useful content from a webpage are not always the same thing.

A request can succeed technically while still giving an AI application poor input.

A page might contain:

• navigation menus repeated across every URL
• cookie banners and consent messages
• related-content modules
• promotional blocks
• headers and footers
• advertisements
• widgets unrelated to the task
• or content that only appears after JavaScript runs

An AI application trying to answer a question about a pricing table does not necessarily need everything surrounding that table.

It needs the page context that helps it complete the task.

This distinction becomes more important as web retrieval moves into production. Sending unnecessary page content downstream consumes model context and can make useful information harder to identify.

Unlike a basic web scraping API that returns raw page data, TinyFetch focuses on retrieving cleaner page context that AI applications can use directly.

That is the job TinyFetch is built around.

It is not simply:

“Can I make an HTTP request to this URL?”

It is:

“Can I give my application useful page context from this URL?”

How Does TinyFetch Work?

Take a simple example.

An AI assistant needs to compare the pricing plans of several SaaS products. It already has the pricing-page URLs, so search is no longer the problem.

The workflow can move directly into retrieval.

1. The application sends TinyFetch a URL

TinyFetch begins with the location of the content.

For example:

https://docs.tinyfish.ai/search-api

TinySearch starts with a query when the application still needs to find the right page. TinyFetch starts with the URL itself.

Once the application knows where the information lives, it can go straight to retrieval. A single TinyFetch request can include up to 10 URLs, and each page is processed independently, so a failure on one URL does not prevent the others from returning results.

2. TinyFetch loads the webpage

Many webpages do not expose all of their useful content in the initial HTML. Pricing tables, product details, documentation, and other page elements may only appear after JavaScript runs.

TinyFetch handles that rendering step before extraction, so the application can work with the content that actually appears on the page rather than just the initial response.

It is designed for retrieval, not multi-step interaction. If the task requires clicking through tabs, logging in, submitting forms, or navigating a website, TinyAgent or TinyBrowser is a better fit.

3. TinyFetch extracts useful page content

Once the page has loaded, TinyFetch extracts the content that is most useful to the application.

It can reduce surrounding elements such as navigation, repetitive footers, cookie banners, and ads while preserving useful structure such as headings, paragraphs, lists, links, and code.

The Preview shows the extracted page content in a cleaner, readable format. Developers can also narrow the extraction with CSS selectors, for example by including the main article content while excluding comments or newsletter forms.

4. The application decides what happens next

TinyFetch returns the page content. The surrounding application decides how to use it.

That might mean:

• passing relevant context into a large language model (LLM)
• storing the page for later processing
• feeding it into a retrieval-augmented generation (RAG) pipeline
• comparing it with content from other URLs
• monitoring information across repeated runs
• or passing the result into another step of an agent workflow

TinyFetch handles retrieval. It does not replace the reasoning, validation, or business logic of the application.

Pro tip: If you already have the URL, do not add search simply because your stack has a search API. Start at the lowest layer that solves the job.

Have a URL your agent needs to read?

Paste it into the Fetch Playground and see what TinyFetch returns.

→ Try TinyFetch in the Playground

What Does TinyFetch Return?

TinyFetch supports three main output formats.

Markdown is the default format as shown in the image below. It provides clean content suited to LLM consumption and readable storage. HTML preserves semantic markup, while JSON represents the page as a structured document tree.

There is an important distinction here.

JSON output does not mean TinyFetch automatically converts every webpage into an arbitrary custom business schema.

For example, asking for JSON does not automatically transform any ecommerce page into:

{
  "product": "Aurora 14",
  "price": 1199,
  "availability": "in_stock"
}

Instead, TinyFetch's JSON output preserves the document's structure in a machine-readable form.

The larger job is reliable retrieval of useful webpage content.

TinyFetch Use Cases for AI Agents and Applications

TinyFetch fits into workflows where the application already knows which source it wants to read.

Give research assistants full-page context

Research rarely ends when an application finds a URL.

Suppose a research assistant discovers an industry report, a company announcement, or an official documentation page. The search result may tell the application that the page is relevant, but the agent still needs the actual content before it can evaluate the evidence.

TinyFetch can retrieve that page and return cleaner content for the next step.

This creates a simple workflow:

TinySearch finds the source → TinyFetch retrieves the source → the application reasons over the evidence.

Not every research workflow needs both, but they naturally work together when the URL is discovered through search.

Retrieve documentation for RAG and AI applications

Documentation is a common input for AI applications because it contains the detailed information models need to answer technical questions accurately.

If an application knows the documentation URLs it needs, TinyFetch can retrieve the content and return it as Markdown, HTML, or JSON.

The surrounding RAG system still owns decisions such as:

• how content should be chunked;
• which documents should be indexed;
• how embeddings are generated;
• how retrieval is ranked;
• and how the final answer is produced.

TinyFetch provides the webpage input. It is not the RAG system itself.

Read product and pricing pages

Known product URLs are another straightforward Fetch use case.

An application might retrieve:

• pricing information
• product specifications
• policy details
• plan descriptions
• documentation
• or other information from known pages

For example, a procurement assistant comparing five vendors could retrieve five pricing pages and pass their content into the comparison workflow.

If the information requires clicking through tabs, navigating filters, logging in, or completing several website actions, the job has moved beyond simple retrieval.

Use TinyAgent when you want TinyFish to complete the workflow from a goal, or TinyBrowser when your own automation code needs direct control over the browser.

Retrieve content from JavaScript-heavy pages

A URL might be public and still be difficult to retrieve with a simple HTTP request.

TinyFetch supports dynamic, JavaScript-heavy, and single-page application content that becomes available during page rendering.

That lets developers focus on the content their application needs rather than building a browser-rendering layer for every fetch.

Why Clean Web Content Matters for AI Agents

A webpage was designed for a person using a browser.

An LLM does not experience that page the same way.

A person can visually ignore the navigation bar, newsletter banner, related stories, footer links, and other surrounding elements. A model receiving the page as text may have to process all of it.

That creates three practical problems.

Irrelevant content consumes context

Every piece of text sent to a model occupies part of its context window.

If most of the input has nothing to do with the actual task, the application is spending context on information it does not need.

This becomes especially noticeable when an agent reads several pages in one workflow.

More input can mean more downstream cost

Model input is not free.

Longer page content can increase token usage and add latency to downstream reasoning. Unnecessary context still has to be processed by the model even when it contributes little to the final answer.

The goal is not simply to produce fewer tokens at any cost.

It is to preserve the information that matters while removing unnecessary surrounding content.

Modern pages may need to be rendered first

Cleaner extraction only helps if the relevant content was retrieved in the first place.

That is why browser rendering matters.

TinyFetch loads pages in a browser when needed before extraction, allowing dynamically rendered content to become part of the result.

Key takeaway: Good web retrieval is not just about whether the request returned 200 OK. The more useful question is whether the application received enough relevant page context to complete the task.

TinyFetch vs. TinySearch vs. TinyAgent vs. TinyBrowser

The easiest way to understand TinyFetch is to separate the TinyFish primitives by the job each one performs.

Use TinySearch when you need to find the page

The application knows what information it wants but does not know where it lives.

Search first.

Use TinyFetch when you already know the page

You have the URL and need the page content.

Fetch it.

Use TinyAgent when reading is not enough

The job requires navigation, filters, pagination, forms, authentication, or decisions across multiple website steps.

At that point, the application needs to operate the website rather than simply retrieve a page.

TinyAgent takes a goal and performs the multi-step workflow needed to complete it.

Use TinyBrowser when your own code controls the browser

TinyBrowser is browser infrastructure.

It gives developers a managed browser session that their own automation controls. Use it when you want to drive the browser directly using your own Playwright, Puppeteer, or CDP-based automation rather than giving TinyFish a goal to complete.

The distinction is straightforward: TinySearch, TinyFetch, and TinyAgent perform web tasks, while TinyBrowser provides the managed browser session your own automation code controls.

Already know where the information lives?

Skip search and give TinyFetch the URL directly.

→ Try TinyFetch

Is TinyFetch Free?

Yes. TinyFetch is free within its published usage limits and does not consume Wallet credits.

TinySearch is also free, while TinyAgent and TinyBrowser use usage-based pricing. This makes TinyFetch an easy starting point for applications that need reliable webpage retrieval before moving into more interactive browser or agent workflows.

TinyFetch Caching and Freshness Controls

Not every application needs to reload the origin page on every request.

A documentation page that changes once a month has different freshness requirements from a pricing page being checked during a purchase decision.

TinyFetch therefore gives the application control over freshness.

By default, Fetch may return an existing cached result when one is available. Developers can use the ttl parameter to specify how fresh an accepted result needs to be, or set ttl to 0 when the workflow requires a live fetch from the page.

That lets the application choose the right trade-off for the job rather than treating every URL identically.

Editorial check before publication: Link ttl to the current TinyFetch API reference and confirm that ttl=0 still forces a live fetch before publishing this section.

How to Get Started With TinyFetch

You need Python 3.11 or later and a TinyFish API key before making your first request.

Install the TinyFish Python SDK:

pip install tinyfish

Set your API key as the TINYFISH_API_KEY environment variable:

export TINYFISH_API_KEY="your_api_key"

Then make a Fetch request:

from tinyfish import TinyFish

client = TinyFish()

response = client.fetch.get_contents(
    urls=["https://www.tinyfish.ai/"]
)

if response.results:
    page = response.results[0]
    print(page.title)
    print(page.text)

if response.errors:
    print(response.errors)

Checking both response.results and response.errors is useful because individual URLs can fail independently, particularly when multiple URLs are submitted in the same request.

The same API is available through TypeScript and cURL, and TinyFetch can also be used through TinyFish integrations such as MCP and the CLI.

From there, the application can choose its output format, control freshness, retrieve multiple URLs, or scope the content to specific parts of a page.

Use TinyFetch When You Already Know the URL

Web retrieval does not have to begin with a complicated agent workflow.

If your application already knows where the information lives, the first job may simply be to read the page properly.

TinyFetch takes that known URL and turns the webpage into cleaner content the rest of the application can use.

Use TinySearch when you need to find the page. Use TinyFetch when you already have the URL. Move into TinyAgent when the task requires goal-based interaction, or TinyBrowser when your own automation needs direct control of the browser.

Have a page your agent needs to read?
Try the URL in the TinyFetch Playground and inspect what comes back.

→ Try TinyFetch in the Playground

Related Reading

• Production-Grade Web Fetching for AI Agents TinyFish
• 80% of Your Web Fetch Returns Junk TinyFish
• Search and Fetch Are Now Free for Every Agent, Everywhere TinyFish
• Agentic Search Architecture: How Production-Ready Search Agents Work TinyFish