Scraping JavaScript-rendered pages needs a browser when the useful content appears only after scripts run. Many pages already send their text in the first HTML response, so inspect that response before paying the time and resources for rendering. A browser also does not guarantee access to a page that blocks your IP or requires a login.
url2llm handles rendering automatically. Choose the output you need, such as Markdown, a screenshot or branding.
When does scraping a JavaScript-rendered page need a browser?
Fetch the page as plain HTTP and inspect the returned HTML. Search for the title, primary text, or product fields your application needs. If the HTML contains only a shell and the browser later fills it, rendering may be necessary. Google's JavaScript SEO guide explains how JavaScript-generated content can differ from the initial response.
Do not judge by a framework name alone. A React or Next.js site may render useful content on the server. A plain-looking page may load its data later. The question is whether the response contains the data your application needs.
What should you compare after rendering?
Compare the extracted text with the visible page. Check the heading, main body, tables, links, and any text that changes after interaction. If the visible page is complete but the extraction is thin, the problem may be content selection rather than rendering. If the visible page is itself blocked, another extraction format will not fix it.
| Symptom | First check |
|---|---|
| HTML is a shell | Render in a browser and inspect the DOM |
| HTML has the text, Markdown is thin | Inspect extraction and main-content settings |
| Page shows a 403 or challenge | Diagnose access and address reputation |
| Screenshot is incomplete | Check load timing and delayed content |
How do you handle delayed content?
url2llm checks page readiness before extracting rendered content, including fonts, visible images and a brief period without content changes. The wait is bounded so pages that keep updating do not hang the request.
For pages that need additional time, waitFor adds a delay in milliseconds. For example, {"url":"https://example.com/app","formats":["markdown"],"waitFor":1000} adds a one-second wait. A fixed delay cannot repair content that requires a click or authentication.
What should you do next?
Try one page in the url2llm playground with Markdown, then compare it with the visible page. Request a screenshot only if the visual state matters. For a 403, follow the block diagnosis guide. For a pipeline that turns the result into model context, see website to Markdown.
Measure completed useful pages, not just whether the browser launched. Rendering solves a content-timing problem. It does not solve every extraction or access problem.