React rendering
Compare source HTML with rendered output before scraping the app
React websites can look complete in a browser while the first HTML response contains only a small app shell. ScraperFly helps teams prove that difference before they build parser logic, queue workers, or browser infrastructure around the wrong response.
Start with source HTML, inspect what the target actually returns, then enable browser rendering, waits, sessions, headers, country routing, or visual output only when the rendered React page gives your workflow better evidence.
Why are React websites different to scrape?
React websites often separate the first server response from the page a user finally sees. The source HTML may contain a root element, script tags, route metadata, hydration data, or a small placeholder. The useful product cards, article sections, search results, prices, tables, reviews, filters, or profile content may appear only after JavaScript runs in the browser.
That does not mean every React page needs the heaviest scraping profile. Some React applications still expose useful metadata, embedded state, server-rendered content, or structured payloads in the initial response. Others need rendered HTML because the content is built client-side. The practical workflow is to compare both states before deciding how the page should be captured.
Practical takeaway: React scraping should begin with evidence, not assumptions about whether the page needs a browser.
What should you inspect before rendering a React page?
The first check is the source response. Look for the useful content, not just a successful status code. A 200 response can still be an empty shell if the page expects the browser to fetch data, hydrate components, and build the final DOM. Inspect the body, response size, script payloads, metadata, final URL, and whether the target fields appear in the HTML your parser receives.
If source HTML already contains the fields you need, keep the request simple. If source HTML misses the useful content, compare rendered output. If rendered output changes the DOM in a meaningful way, rendering is justified. If rendered output is still empty, the issue may be timing, routing, blocked resources, a bad route, unavailable public content, or a page that requires a different workflow.
| React signal | What it means | Best next step |
|---|---|---|
| Source HTML contains target content | The page can likely be captured without browser rendering | Use a lightweight HTML request and build the parser from source evidence. |
| Source HTML is mostly a root element and scripts | The page probably builds useful content in the browser | Test rendered HTML before writing extraction logic. |
| Rendered DOM contains the target fields | JavaScript execution changes the scrape result | Use rendering for this page type and log why it is needed. |
| Rendered page is still incomplete | The issue may be timing, request context, routing, or target behavior | Inspect wait timing, status, final URL, response size, and visual proof. |
| Visual page differs by region or state | The route may depend on location, cookies, headers, or session continuity | Add context deliberately instead of making every request heavier. |
When should ScraperFly render a React website?
Enable rendering when the useful public content appears after client-side JavaScript runs. Common examples include React product grids, search results, dashboards with public data, route-based article pages, lazy sections, review widgets, price blocks, filters, and pages where the first HTML response contains placeholders rather than the final content.
Rendering should be precise. Do not turn it on because the site uses React; turn it on because the raw response does not contain what the workflow needs and the rendered response does. This keeps simple pages fast and affordable while still giving browser-built pages the environment they need.
For broader browser capture decisions, use the JavaScript rendering API guide and the headless browser scraping API page. For source-first targets, compare the HTML scraping API approach before making rendering the default.
Which output format works best after React rendering?
Rendered HTML is the best choice when your parser needs the final DOM, selectors, attributes, links, tables, product cards, or route content. Text and Markdown are better when the React page should feed search, summaries, AI context, documentation review, or RAG ingestion without layout noise. JSON metadata is useful for logging request evidence. Screenshots and PDFs are useful when a human needs to verify what the rendered page looked like.
This choice should happen before building converters. A React scrape that feeds a parser may need rendered HTML. A React scrape that feeds an LLM may be better as Markdown. A monitoring workflow may need metadata plus a screenshot. A compliance or QA workflow may need a PDF. ScraperFly lets the request return the shape the downstream system can use immediately.
| React workflow | Output to test | Why it helps | When to avoid it |
|---|---|---|---|
| DOM parsing | Rendered HTML | Returns the page after React builds useful markup | When source HTML already contains the target fields. |
| Content ingestion | Text or Markdown | Removes much of the layout noise before search or AI processing | When exact selectors or DOM relationships matter. |
| Diagnostics | JSON metadata | Shows status, final URL, content type, response size, and request context | When the workflow expects extracted target fields by itself. |
| Visual QA | Screenshot | Confirms what the rendered public page looked like | When the workflow only needs machine-readable text. |
| Archive or approval | Creates a portable record for review | When the content needs frequent automated parsing. |
How should waits, sessions, headers, and routing be handled?
React pages can fail for reasons that look similar from the outside. A page may need extra wait time because data loads after initial render. It may need headers because the public route expects language or content context. It may need sessions because related requests rely on shared cookies or state. It may need country routing because content changes by region, currency, or availability. It may need stronger delivery when the simple path repeatedly returns unusable output.
The right answer is not to enable everything. Add one control at a time and compare the result. If a wait fixes missing content, record the timing reason. If sessions change the response, keep them only for that related flow. If region changes the page, keep country routing tied to the target. A React scraping workflow is easiest to operate when every enabled control has a visible reason.
Use sessions for stateful public flows, custom headers for legitimate request context, and routing controls when delivery path changes the result.
What failures are common when scraping React websites?
The most common failure is treating an empty source response as a target block when it is really just a normal React shell. Another common failure is rendering too quickly and capturing the page before client-side data finishes loading. Teams also run into route redirects, content that changes by region, oversized responses, missing public data, unsupported output choices, and workflows that expect the API to extract application state automatically.
Good error handling keeps those cases separate. Compare source HTML, rendered HTML, screenshot state, final URL, status, response size, and wait timing. Fix malformed inputs and unsupported options instead of retrying them. Retry temporary failures with bounded backoff. Escalate routing only when repeated evidence shows the simple path is not enough.
The error-handling block below gives a broader failure framework. For React pages, the key is to distinguish "the browser has not built the page yet" from "the target returned a bad page" and from "the request profile is wrong."
How can React scraping stay affordable?
Rendering is powerful, but browser work is heavier than a simple HTML request. Cost stays predictable when teams classify targets before scaling: raw HTML pages, rendered React pages, pages that need waits, regional routes, session-dependent flows, visual QA captures, and PDF archives. Each class should have its own request profile instead of inheriting one expensive default.
This is where ScraperFly's path is practical. Start free, test real React pages, keep simple captures light, and use heavier controls only where they change the response. A one-off project can stay flexible with credits, while recurring rendered workloads can move to a monthly plan once the profile is proven.
Review pricing after sampling real targets, not before. The useful estimate is based on how many pages truly need rendering, waits, visual output, sessions, or stronger delivery.
Where should a team start?
Start in the API Builder with one public React URL. Request source HTML first. If the useful content is missing, enable rendering and compare the result. Then choose the response format your workflow can use: rendered HTML for parsers, text or Markdown for readable content, JSON metadata for diagnostics, screenshot or PDF for visual proof.
Once the request profile is proven, move it into cURL, Python, Node.js, a backend queue, a monitoring job, or an agent workflow. Keep the profile explicit so future failures can be diagnosed from evidence rather than guesswork.
