Beyond the Renderer String: GPU Evidence from Eight Scraping Providers

One browser, two GPU stories

In one captured browser, WebGL reported Intel while WebGPU reported Apple. In two others, the reported GPU identity stayed consistent, but selected worker outputs matched software-rendering pilots.

Those differences are what made this evaluation interesting. A renderer string gives a name. Comparing APIs and execution contexts reveals whether the rest of the browser tells the same story.

We sent the same research page through eight scraping and browser providers. Three captures explicitly reported software rendering. Five reported consumer GPU identities. We examined the claims alongside capabilities, repeatable rendering, and behavior outside the main page.

The question is how reported identities relate to measured behavior. The findings below are evidence from specific sessions, with alternative explanations still open. They do not establish a provider-wide spoofing verdict.

Methodology

GPU Observatory is our browser-side research instrument. It collects graphics identity, capability, and rendering observations, then checks selected relationships between them. This evaluation used suite 0.3.0 on 6 October 2026.

Each provider opened the same page in its own browser session. Collection ran inside that browser, across the main document, a same-origin iframe, and a dedicated worker where the relevant APIs were available. Selected observations were repeated within the session to distinguish stable outputs from variation.

The eight selected captures each contain a completed result, a screenshot, and a matching report in the saved HTML. We checked that the embedded HTML reports match the separately retained JSON reports. Synthetic fixtures are excluded.

MrScraper’s selected capture used its super mode. ScrapingBee’s used its stealth proxy mode with US routing. These product configurations belong to the result and should not be generalized to every mode offered by those providers.

Sampling scope: one captured session per provider configuration. Measurements repeated inside a session are not independent sessions or proof of consistency across a provider’s fleet. Browser versions and reported operating systems also differed.

The article describes the measurement families and findings without publishing the exact probe parameters, reference signatures, or implementation. The instrument’s small reference collection contains experimental stack pilots, not calibrated hardware cohorts.

Findings

The overview

The suspicion index summarizes detected evidence on a scale out of 100. It is not a probability of spoofing, an accuracy measure, or a score of scraping quality. Zero means no assessed masking indicators were found in that capture.

Coverage counts unique probe/API/context observations, not individual parameters or repeated samples. The denominator excludes three intentionally deferred observations. The six unavailable observations in the software-renderer captures concern WebGPU. Higher coverage establishes more available evidence, not more authentic hardware.

The screenshots display the index with a percent sign. Read it as an experimental index out of 100 throughout this article. Select a screenshot to open a zoomable preview without leaving the article.

1. Software rendering was reported openly

ScraperAPI, Firecrawl, and Browserless each reported an ANGLE renderer identifying SwiftShader over Vulkan. The tool found no assessed masking indicators in these sessions.

Chromium describes SwiftShader as a software graphics implementation that runs on the CPU. A browser exposing a SwiftShader identity is therefore reporting a software-rendering path. Our measurements do not independently attest its underlying execution environment.

Software rendering is not itself a masking finding. It also does not tell us whether a provider will succeed against a particular anti-bot system, how quickly it will render a target, or whether its infrastructure uses physical GPUs elsewhere.

2. Consumer GPU claims can remain internally consistent

The scrape.do capture reported Intel HD Graphics 5500 through WebGL and Intel through WebGPU. ZenRows reported Apple M3 through WebGL and Apple through WebGPU. Neither produced assessed masking indicators in the selected checks.

That agreement is a useful observation. It does not validate the exact model, establish physical GPU access, or exclude a consistently replaced surface. Comparable Intel and Apple hardware cohorts were absent from the instrument’s reference collection, so claimed-stack reference agreement remained unassessed.

3. MrScraper exposed a cross-API identity mismatch

In MrScraper’s super-mode capture, WebGL consistently reported Intel Iris Plus Graphics 655 through ANGLE Metal. WebGPU reported Apple, in both the main document and worker.

This is a concrete disagreement between browser-visible APIs. The instrument recorded it as an identity-seam finding and assigned an index of 45/100.

Partial identity replacement is one possible explanation. Different adapter selection is another. Without verified hardware and control over the browser configuration, this capture cannot establish which explanation applies.

An earlier capture without super mode had unavailable graphics and an unassessed result. It is not the selected screenshot below. The difference between the captures reinforces why the product mode and API availability belong in the report.

4. Zyte and ScrapingBee differed beneath the identity string

Zyte reported Intel UHD Graphics through WebGL and Intel through WebGPU. ScrapingBee’s stealth-proxy capture reported AMD Radeon through WebGL and AMD through WebGPU. Unlike MrScraper, their reported vendor families agreed.

The interesting finding appeared in the worker. Selected capability, precision, floating-point rendering, and blending signatures exactly matched alternative SwiftShader pilots while the reported identities still named consumer GPUs. In both captures, the main-document and worker floating-point outputs differed, although the outputs repeated consistently within their respective contexts.

Both captures reported Windows and Chrome 152. The relevant pilots came from Linux with different Chromium versions. The instrument therefore treated the matches as out-of-scope candidates and assigned the lower index of 25/100.

An exact match in these selected tests does not uniquely identify SwiftShader. Driver and backend variation, rounding behavior, or overlapping signatures remain possible explanations. The evidence supports further investigation into the relationship between the claim and the worker surface. It does not establish the provider’s actual hardware or a deliberate spoofing mechanism.

What this means for browser infrastructure

For teams building scraping products, the useful question extends beyond which GPU name appears in a screenshot. A browser identity includes a collection of observable surfaces, and the relationships between those surfaces can matter as much as the individual values.

These captures show why a main-page identity check alone can miss interesting evidence. MrScraper’s finding needed a comparison between APIs. The Zyte and ScrapingBee findings needed a comparison with worker behavior. The software-renderer captures, meanwhile, show why honest software rendering should not automatically become a masking accusation.

This evaluation did not test anti-bot acceptance, extraction quality, latency, throughput, or cost. It cannot tell a founder which provider will work best on their targets. It provides a narrower infrastructure observation and a set of questions worth investigating under controlled conditions.

Limitations

• One captured session per configuration cannot characterize a provider’s entire fleet or establish how often a finding occurs.
• Reported GPU identity, operating system, and browser metadata are claims. We did not verify the underlying machines, drivers, or adapter selection.
• The reference pilots are small and uncalibrated. The Zyte and ScrapingBee candidate matches are outside their browser/OS scope, and signature overlap is possible.
• Within-session repeatability does not prove authenticity. A consistently modified surface can remain consistent across every inspected context.
• Unavailable APIs are missing evidence. A zero index is not proof of no spoofing, and an unassessed result is not zero.
• The instrument inspects selected graphics behavior. It does not recover physical GPU identity or measure the effectiveness of any anti-bot bypass.
• Screenshot widths and original viewport layouts vary. Prepared images were cropped for presentation, without resizing or regenerating the page content. Their dimensions are not proof of an identical browser viewport.

Reproduction

The retained evidence consists of completed HTML, matching JSON reports, screenshots, capture metadata, and run identifiers. Those records let us trace each published image to its underlying observations. Earlier incomplete or superseded captures are excluded from the comparison.

The implementation, exact reference signatures, and raw report archive are not published with this article. This is documented testing, not a complete public reproduction package.

Repeating the comparison requires the same suite and protocol, recorded provider modes, completion-aware collection, and fresh sessions. A stronger follow-up would add repeated independent sessions and controlled hardware/browser baselines, then check whether the same findings persist. Even then, browser-visible evidence must be separated from hardware verification and causal explanation.

Sources and research ownership

Provider-specific observations come from our retained captures dated 6 October 2026. GPU Observatory is a ScrapeTrace research instrument. The provider labels shown in screenshots were supplied during collection, rather than independently inferred by the tool. The labels identify the capture route, not an attested infrastructure identity.

For the software-rendering background, see Chromium’s SwiftShader documentation. That documentation explains the implementation, not the particular machines behind these provider sessions.