Glossary

Client-side rendering

The page is assembled in the visitor's browser, so the HTML on the wire is only half the story.

By Roger Campos · Last updated: September 2026

TL;DR

Client-side rendering (CSR) is when the server sends a near-empty HTML shell plus JavaScript, and the browser runs that JavaScript to fetch data and build the page. Anything that reads the HTML without running the scripts — curl, most link previewers, many bots — sees the shell, not the content.

Start free See the API

Free plan, no credit card. 1,000 credits a month.

How it works

How a client-rendered page loads

1
The server answers with a small HTML document: a <div id="root"> or <div id="app"> and one or more <script> tags.
2
The browser downloads and runs the JavaScript bundle.
3
The bundle calls an API for the page's data, then builds the headings, text and images into the empty container.
4
Navigation between pages happens in JavaScript too, without asking the server for new HTML.

A React app built with Vite and no server rendering is the textbook case. The source of every route is the same few hundred bytes; the difference between the pricing page and the blog is decided entirely in the browser.

In practice

What it means when you fetch pages

An HTTP client returns what the server sent, so on a CSR page it returns the shell. There is no text to convert to Markdown, no price to extract, and often no <title> beyond the app's name. To read the page you have to run it, which means a browser.

Running it is not always enough. A CSR page is "loaded" long before its data arrives: the load event can fire while the container is still empty, because the API call the bundle makes is not part of it. That is why rendering tools wait for the network to go quiet, and why a selector to wait for is the dependable answer.

URLpipe

How URLpipe handles it

Every URLpipe endpoint renders the page in real Chrome before reading it, so a CSR page returns its content from /html, /markdown and the rest without any option. The engine waits for the page to settle after load. When the content still arrives later — a slow API, a skeleton screen — name an element that only exists once it has:

POST /markdown

{
  "url": "https://app.example.com/pricing",
  "sync": true,
  "page_options": { "wait_for_selector": ".pricing-table" }
}

An element that never appears fails the request, and a failed request costs nothing. The rendered vs. raw HTML guide shows the two side by side.

Try it

Client-side rendering (CSR), on a page you choose

Get the rendered HTML of any URL

Paste a link and get the page's HTML after JavaScript has run and redirects have been followed — the DOM a real browser sees, not the empty shell curl returns.

Try it free

FAQ

Frequently asked questions

Is client-side rendering bad for SEO?

Not fatal for Google, which renders pages before indexing, but slower to index and invisible to crawlers that only read HTML source — including most AI crawlers and link-preview fetchers.

What is the difference between CSR and SSR?

With server-side rendering the server sends HTML that already contains the content, and JavaScript then hydrates it. With CSR the server sends a shell and the browser builds the content.

Why does my scraper get an empty div?

Because the page is client-rendered: the content is created by JavaScript your HTTP client never runs. Fetch it with a headless browser, or an API that renders it.

Keep reading

Per-project rate limits networkidle Residential proxy Public API documentation at /docs Get the rendered HTML of a JavaScript page in Ruby Polite scraping: robots.txt and pacing All of glossary

See it on your own pages.

Free plan, no card. Confirm your email and your API key is live — you'll be making real requests in minutes.

Start free Email the team